Long ago when the world was new, Marcin Mielzynski modified our Array
implementation to be copy-on-write like MRI. And there was much
rejoicing.

COW helps methods like slice and dup that would normally need to make
a copy of all or part of the source array by wrapping the original
array in "shared" mode. Subsequent modifications force the original
contents to be copied into a new array, but for read-only subsets
(especially if they're big) it's a win.

However, it suffers from a big down side: if you have a really large
array holding onto many large objects, and you slice out a small
subset of that array, the original contents stick around. This is like
a pseudo-leak, since the memory the rest of the array is rooting never
gets collected. We've patched around this in a few key methods.

So today I thought I'd try removing COW from Array completely and
comparing numbers. Here's the result and the patch:

https://gist.github.com/beab95be678c519e8a24

The bottom line is that it definitely has an impact. Any operation
that would create a new view of N elements of the original array goes
from being O(1) (the time needed to wrap the old array contents in a
new object) to O(N) (the time needed to copy all those elements into a
new array.

I post this here so anyone interested in testing it against real code
or real applications can do so. I just used some simple benchmarks
from Rubinius, which certainly aren't going to behave like a typical
app. Maybe the degradation is small enough for real apps that the
GC/memory improvements would be worth it?

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to