In a function with (speed 3) I had (replace s1 s2 :start1 start) and
lived peacefully in the belief that all is well and fast until sbcl ran
out of memory in replace.
I found that :START1 inhibited the double-float double-float
deftransform for replace and it ended up consing up a double and
sticking it into the target array for each element which needles to say
is both slow and wasteful.
The attached patch makes the deftransform deal with this more
gracefully: instead of punting if START1 and START2 aren't the same
constant it leaves the decision until run time about whether it's a
forward or backward copy.
It does not register in sbcl self compile neither in cl-bench
performance. But coupled with gc conservatism this is the difference
for my app between running out of heap or chugging along.
Get latest updates about Open Source Projects, Conferences and News.