On Wednesday, March 16, 2016 at 10:22:40 PM UTC+8, Nicholas Nethercote wrote:
>   Even if we can fix that, it's just a lot of JS code. We can lazily import
>   JSMs; I wonder if we are failing to do that as much as we could, i.e. are
>   all these modules really needed at start-up? It would be great if we
>   could instrument module-loading code in some way that answers this
> question.

B2G also did dropping JS source, for Tarako branch, since source is useless for 
loaded module save for stringify functions.  (Gecko compress in-memory source.) 
But, I am not sure if it was landed on m-c then.

> 
> - "heap-unclassified" memory is 4.5 MiB per process. I've analyzed this with
>   DMD and this is mostly GTK and glib memory that we can't measure in our
>   memory reporters. I haven't investigated closely to see if any of this
> could
>   be avoided.
> 
> - "heap-overhead" is 4 MiB per process. I've looked at this closely.
>   The numbers tend to be noisy.
> 
>   - "page-cache" is pages that jemalloc holds onto for fast recycling. It is
>     capped at 4 MiB per process and we can reduce that with a jemalloc
>     configuration, though this may make allocation slightly slower.
> 
>   - "bin-unused" is fragmentation in smaller allocations and very hard to
>     reduce.
> 
>   - "bookkeeping" is jemalloc's internal data structures and very hard to
>     reduce.
> 
> - Then there's the not-so-long tail of things less than 1 MiB per process.
>   Some of these may be shrinkable with effort, or made shareable between
>   processes with effort. (E.g. I reduced xpti-working-set by 216 KiB per
>   process in bug 1249174, and I've heard that making it shared was
> considered
>   for B2G but never implemented.) It's getting into diminishing returns,
>   though.

xpti sharing was implemented for B2G.  It would be easy to enable them on Linux 
and Mac, but I am not sure on Windows.

I guess preference is worth to be shared too.
atoms-table maybe!
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to