From: Eric Wong <normalperson@...>
Date: 2013-05-13T07:30:31+09:00
Subject: [ruby-core:54941] Re: [ruby-trunk - Bug #8399][Open] Remove usage of RARRAY_PTR in C extensions when not needed

"dbussink (Dirkjan Bussink)" <d.bussink@gmail.com> wrote:
> Rubinius uses quite a few C extensions directly from MRI. Some of
> these use functionality such as RARRAY_PTR which is not necessary. For
> compatibility reasons, RARRAY_PTR works on Rubinius but suffers from a
> heavy performance penalty. Take for example the test of the parser gem
> (http://github.com/whitequark/parser). These run over 10x faster with
> the patch applied to Racc that is submitted here:

I am curious how Rubinius implements RARRAY_PTR and why it cannot be
made faster (especially in the non-resizing case).

Are the native (for Rubinius) memory region for arrays not contiguous?

I also remember asking for RSTRUCT_PTR in Rubinius a few years ago and
was turned down.  I expect Array/Struct to use a contiguous memory
region (regardless of programming language, but I learned C/ASM first)

I don't know much about GC implementation, but I think non-resizing
accesses from C API ought to have no effect (though entering C code
in the first place may be expensive).

> https://gist.github.com/dbussink/57c32c08fb21c7a41719

What is the performance change for MRI?

> Consider issue #8339 where there is work being done on generational
> GC, I think it is also beneficial to remove usage of internal
> structures such as RARRAY_PTR where there is the problem of going
> around the write barrier. In Rubinius, an array is treated special if
> RARRAY_PTR is used on it in the C-API, so I can imagine MRI being able
> to optimize the GC better if extensions don't do this. There are
> functions available for both getting and setting elements in an array
> and they work fine.
> 
> I have only make a patch against Racc here as a showcase, I also want
> to update all the other extensions to remove RARRAY_PTR. Please
> consider this change to MRI since in my opinion it has benefits also
> for MRI and so Rubinius can keep using these extensions directly
> without having to maintain custom versions just for the considerations
> described here. I'm also already actively checking C extension gems
> and sending pull requests for updating this.

Since I maintain a few C extensions myself, I'll be following this and
see how it plays out.