jemalloc 3 performance vs. mozjemalloc
Mike Hommey
mh at glandium.org
Tue Mar 3 18:54:18 PST 2015
On Wed, Feb 18, 2015 at 07:15:11PM +0900, Mike Hommey wrote:
> On Wed, Feb 18, 2015 at 06:34:26PM +0900, Mike Hommey wrote:
> > On Wed, Feb 04, 2015 at 11:54:32AM +0900, Mike Hommey wrote:
> > > On Wed, Feb 04, 2015 at 07:51:17AM +0900, Mike Hommey wrote:
> > > > Hi,
> > > >
> > > > I've been tracking a startup time regression in Firefox for Android when
> > > > we tried to switch from mozjemalloc (memory refresher: it's derived from
> > > > jemalloc 0.9) to mostly current jemalloc dev.
> > > >
> > > > It turned out to be https://github.com/jemalloc/jemalloc/pull/192
> > >
> > > *sigh* and sadly, this doesn't fix it all :(
> >
> > So, it /might/ be related to the size classes. I don't have all results
> > yet, but it looks like I'm getting good results with #192,
> > --with-lg-quantum=4, --with-lg-tiny-min=2 and replacing size2index,
> > index2size and s2u so that jemalloc3 uses the same size classes as
> > mozjemalloc (IOW, a very bastardized jemalloc3)
> >
> > If that happens to be true, I'll dig deeper as to what particular size
> > classes changes are making a difference.
>
> And with more results coming in, it's starting to look like it was a red
> herring :(
> The comment about the size classes well above the chunk size still stands,
> though.
... and we do have regressions on x86 as well, on, presumably,
allocation intensive workflows. We also have a RSS regression on
Windows that I'll have to look at more closely.
Mike
More information about the jemalloc-discuss
mailing list