On Tue, Nov 12, 2013 at 09:24:23AM -0500, John Cowan wrote: > 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.
Simple: for those who prefer functional updates, but don't want their lists to keep growing endlessly. Also, in some cases duplciate entries really mean something different (for example in alist->uri query attribute mappings and such). You could argue that means they're not true alists, but it sometimes is convenient to treat them as such. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
