On Mon, November 10, 2014 6:51 pm, Nicholas Nethercote wrote: > Hi, > > I've been doing some heap allocation profiling and found that during > basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not* > live) heap allocations. We're talking gigabytes of allocations in > short browsing sessions. That is *insane*.
Could you explain why it's insane? I guess that's sort of why I poked you on the bug. Plenty of allocators are rather smart under such churn, and NSS itself uses an Arena allocator designed to re-use some (but understandably not all) allocations. Is there a set of performance criteria you're measuring? For example, we're spending X% of CPU in the allocator, and we believe we can reduce it to Y%, which will improve test Z. Not to be a pain and discourage someone from hacking on NSS (we always need more NSS hackers), but I guess I'm just trying to understand the complexity (and locally caching / lazy instantiating always adds some degree of complexity, though hopefully minor) vs performance (which is hopefully being measured) tradeoffs. Further, if we aren't continuously monitoring this, meaning it's not a metric integrated as something we watch, then it seems very easy that any improvements you make can quickly regress, which would be unfortunate for your work. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
