in reply to Perl + Hoard ?

I have an experience that perl's own memory allocator is pretty good.
I am curious why it is not *on* by default.

Once I successfully built Perl together with Tcl/Tk both using Perl's memory allocator and found this gave me considerable speed improvement.

This experiment gave me an idea that using other memory manager is an easy task. You only need to override 3 or 4 functions and go figure out the results.

But Perl's memory allocator is *sooo* efficient that it hardly can be ever bitten, because it was written far in the past, when people bothered somehow on efficiency.

Replies are listed 'Best First'.
Re^2: Perl + Hoard ?
by renodino (Curate) on Nov 27, 2006 at 23:42 UTC
    I have an experience that perl's own memory allocator is pretty good.

    I agree...except that, in its zeal to provide optimal performance, it makes some choices wrt threads that create add'l issues for sharing memory between threads, namely, the thread that malloc()'s something must be the thread to free() it (in order to avoid the overhead of heap locking). Presumably, Hoard avoids this (just how, I haven't yet fully researched).

    Which led to my curiousity if anyone had used Hoard (with Perl or anything else), and to ponder if it might be a means to achieve the performance wo/ the threading restrictions.

[reply]
      you're right WRT thread safety... but Perl's thread robustness will not increase with switchnig to threads-friendly memory allocator,
      because, AFAIU switching off Perl memory allocator (so returning to default configuration) will use OS memory manager, which is thread safe by definition.
[reply]
Re^2: Perl + Hoard ?
by eyepopslikeamosquito (Archbishop) on Nov 28, 2006 at 15:54 UTC

    I have an experience that perl's own memory allocator is pretty good. I am curious why it is not *on* by default.
    Apart from thread safety, there is the issue of "bug compatibility" with the system malloc when using buggy third party libraries. I've seen cases where third party libraries erroneously call free on a pointer that was not got from malloc, yet the system malloc is forgiving and does not crash. Now if you replace the system malloc with a pickier one that does crash ... In one way, that is good because you've just flushed out a bug in the third party library. OTOH, you may not have the source code for the third party library to fix it and the vendor may be unresponsive. Most third party libraries are tested primarily with the system malloc and work more reliably with it.

    See also Using Perl's Malloc.

[reply]

In Section Meditations