On May 9, 2013, at 04:28 , Marvin Humphrey <[email protected]> wrote:
> I coded up a Perl benchmark script using Inline::C which approximates the
> optimization under best-case conditions. (See below my sig.)
>
> Here are results on one system:
>
> Rate heap_latin1 heap_utf8 stack_latin1 stack_utf8
> heap_latin1 4591346/s -- -6% -67% -69%
> heap_utf8 4906438/s 7% -- -65% -66%
> stack_latin1 13849117/s 202% 182% -- -5%
> stack_utf8 14588883/s 218% 197% 5% --
I get a speedup of about 130% on OS X, and 90% on a Linux system.
> That's not nothing, but it's not a 10x speedup either. Perl's subroutine call
> overhead is pretty substantial. Other languages may be better, but I bet
> Python and Ruby are comparably sluggish.
If a host language has immutable strings, it might be possible to retain a
reference to the host language string. So the string buffer would never have to
be copied.
> In the abstract, I like stack-allocated host string wrappers because the
> approach is appropos to the Clownfish mission. But if they require sacrifices
> to the API (CAPTURE is inferior to INCREF), a gnarly implementation,
> and they don't speed things up all that much anyway, it may be time to give up
> on them and focus on other things.
> If we start translating to string SVs to Clownfish Strings the way that we
> translate AVs to VArrays and HVs to Hashes, we'll need to mortalize them so
> they don't leak on exceptions.
>
> From XSBind_maybe_sv_to_cfish_obj:
>
> if (retval) {
> // Mortalize the converted object -- which is somewhat
> // dangerous, but is the only way to avoid requiring that the
> // caller take responsibility for a refcount.
> SV *mortal = (SV*)Cfish_Obj_To_Host(retval);
> CFISH_DECREF(retval);
> sv_2mortal(mortal);
> }
>
> That will make things slower still, but it's probably worth it for the sake of
> correctness.
Good point. I'd say we keep this optimization and switch to CAPTURE/RELEASE. I
was only hoping we could find a way to reduce the amount of copying.
By the way, we'll have to rename Lock#Release and maybe MemoryPool#Release_All
and FileHandle#Release_Window to avoid confusion.
Nick
