10:23:10|3b|even then, cache when they change rather than on access might win unless they changee more than they are read
10:23:11jackdanielbecause it doesn't cons unnecessarily, doesn't reverse and keeps pointer to the list end
10:23:58jackdanieloh, sorry, uiop:while-collecting does a lot of things, I'd go with cmuutil collect macro after all
10:24:22|3b|ACTION also notes that the performance loss from non-destructive split probably wouldn't show up on that page load anyway :p
10:24:46|3b|(which admittedly isn't a very good argument in favor of it)
10:25:03axionYeah, I don't need this to be 'fastest possible'. Just not 'slowest possible'.
10:25:26axionI am not trying to introduce bottlenecks when I scale this larger
10:25:52phoemy algorithm: grab references to 1st and 2nd cons of the list. set the CDR of the first cons to the 3rd cons, set the CDR of the first cons to the CDDDR of the first cons, set the CDR of the second cons to the CDDDR of the second cons. Use the CDRs of the first and second cons as the new values for the first and second cons, loop until the CDRs of the lists are NIL.
10:26:50axionThe simplest code can be continually made 'fastest possible' over a lifetime for a programmer. I should have known better to phrase that a bit better
10:33:12axionbeach: So is a lot of things here, such as algorithm efficiency and Emacs buffer data structures being a bad data structure for their use :)
13:14:41rk[ghost]it would probably suit me to spend a few days reading the common lisp hyperspec more or reading others code more than programming.. as it seems like every day i come across a new library function which implements something i already spent time implementing by hand.
13:24:22pjbrk[ghost]: notice that: (let* ((k1 "k1") (k2 "k2") (a (acons k1 1 (acons k2 2 nil)))) (assoc k2 a)) #| --> ("k2" . 2) |# works perfectly with strings and without :test.