jemalloc?

[Miguel Sousa Filipe]

Hi,

On 12/14/06, Vlad Galu <dudu at dudu.ro> wrote:
On 12/12/06, Justin C. Sherrill <justin at shiningsilence.com> wrote:
> On Tue, December 12, 2006 10:21 am, Joerg Sonnenberger wrote:
> > On Tue, Dec 12, 2006 at 04:31:04PM +0200, Vlad Galu wrote:
> >>   I've compiled $subj as a shared library that I preload when using
> >> some test programs and it's been behaving nicely. Are there any plans
> >> to import it? phkmalloc is painfully slow when freeing numerous small
> >> objects.
> >
> > Not for me. phkmalloc has the nice propery of being tight on space
> > usage, which is important in some area. It could be done better, but
> > most applications with very special performance needs have specialised
> > mallocs anyway, so I don't care that much.
>
> Is there a way to measure the space usage difference?  We have hard
> jemalloc numbers that show a benefit, and I'd like to quantify any
> counter-arguments.
   It looks like the extra spage usage was fixed by Jason Evans around
March. The Google link provided by Freddie Cash pretty much covers
every info you needed. I can perform further benchmarks if needed. But
I think I'll not do it, given the reluctance on the list. I'm
certainly not the best judge for this level of technical detail.

If it is presented a (measured) better alternative than the present
one, and if there is someone willing to "integrate" that alternative,
I see this has a one way street..
Oposing such enhancement on the basis of "there are other ways that
are better", but no code is seen is just "talking about it", and
doesn't fix any of the current shortcommings.
If there are no drawbacks to the alternative suggested implementation
regarding the current imlpementation, oposing forces should provide
some even better (measurable) approach/code.
Or we will keep a implementation that is worse, and nothing is gained.
In the future, if some even better (mesurable) approach comes along,
the same logic is valid.
I think that what I am saying is common sense.

Best regards,

--
Miguel Sousa Filipe