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
