RBX GC performance issues

[chuckremes]

As requested, here is a small benchmark showing a perf issue with the rbx GC.

https://gist.github.com/739693

Running this same code under MRI completes in about 300ms.

Running with profiling turned on shows most of the time is spent in Tuple.new and Tuple#copy_from.

Interestingly, a pure "append" operation is wicked fast whereas inserting at the end causes a lot of tuple copies.

[dgtized]

I could be wrong on this, but I believe the problem here is that Array#<< can use the fast path to the primitive, but that insert actually calls self[index, 0] = items, where items is the array of remaining values passed to insert.

The unfortunate result of this is that when you resize for an inplace insertion of an array, then we don't pre-allocate a new tuple that is 1.5 times the size of the previous tuple, and just resize to the exact additional space required.

The GC is doing exactly what it's supposed to here as far as I know, it's just array is triggering a Tuple#new and a Tuple#copy_from on every single insert.

The relevant lines in Array#set_index are from 248 to 275 in kernel/common/array.rb. Also line 930 in the same file shows where Array#insert is using set_index. I remember commenting at the time that we were using two paths for array resizing which meant that one was optimal and one was not, but we were looking at alternate array storage mechanisms at the time so we didn't fix it.

[evanphx]

Remove pathalogical case from Array#[]=. Closed by a6952da.