>On Thu, Jul 12, 2018 at 08:56:28AM -0700, Andrew McCreight wrote: >>On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez <emi...@crisal.io> >>wrote: >> >>> Just curious, is there a bug on file to measure excess capacity on >>> nsTArrays and hash tables? [snip] >I kind of suspect that improving the storage efficiency of hashtables (and >probably nsTArrays too) will have an out-sized effect on per-process >memory. Just at startup, for a mostly empty process, we have a huge amount >of memory devoted to hashtables that would otherwise be shared across a >bunch of origins—enough that removing just 4 bytes of padding per entry >would save 87K per process. And that number tends to grow as we populate >caches that we need for things like layout and atoms.
Hash tables are a big issue. There are a lot of 64K/128K/256K allocations at the moment for hashtables. When we started looking at this in bug 1436250, we had a 256K, ~4 128K, and a whole bunch of 64K hashtable allocs (on linux). Some may be smaller or gone now, but it's still big. I wonder if it's worth the perf hit to realloc to exact size hash tables that are build-once - probably. hashtable->Finalize()? (I wonder if that would let us make any other memory/speed optimizations if we know the table is now static.) -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list email@example.com https://lists.mozilla.org/listinfo/dev-platform