Peter Bex scripsit: > alist-update will take O(n) to locate the key just like alist-update!, > but when it finds the entry, it will need to build a new list with > the entry replaced at the same position. That means it's O(n) to update > (for new keys it's O(1), they can just be consed onto the front). > In total, that's O(2n). The major extra time you see can not be > explained due to that, but the output of time gives a clear hint.
Why was alist-update introduced, anyway? It is more efficient to use either alist-update! or alist-cons (from SRFI 1) in any situation I can think of. I note that neither SRFI 1 nor the alist-lib egg has it. -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot [email protected] that I foolishly ate out of an illjudged faith http://ccil.org/~cowan in the benignancy of vegetables. --And Rosta _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
