Personally, I would like to encourage your efforts. If you are able to
move many of these allocations from heap-based with locks, to something
stack-based instead, this will improve NSS server performance
tremendously. I would be surprised if it was a significant boost to
client apps like Firefox, though.
On the other hand, I'm not sure that there is that much low-hanging
fruit, based on the stacks you list in the bug.
Many are dictated by the design of NSS, the PKCS#11 API, and the current
softoken implementation.
Working within these constraints is not so simple. Keep in mind that
many things you might want to change cannot be, in order to preserve NSS
API binary compatibility.
Julien
On 11/10/2014 18:51, 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*.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about
this. I've written several patches that fix problems, one of which has
r+ and is awaiting checkin; check the dependent bugs.
This is making Ryan Sleevi is nervous and he wanted me to post
something here about my plans. So here they are: I want to reduce
unnecessary allocations. I want to do so in a very non-intrusive
fashion: I'm aware that NSS is security-sensitive code, and TBH it's
not that enjoyable to read or modify. I will plug away at this as long
as there is low-hanging fruit to be found, which may not be that much
longer.
Nick
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
