Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : source : 5fb0b7746a5d56563b471e3061ccca124ea45485
extra : absorb_source : 275f5d4dc2c02e3d0391ed16e8690dac1e601758
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : source : 8359f8fe418419c50ab0ed93496e7445b570ba9f
extra : absorb_source : 2a33ae4e7e6d312adcea8ece2158f07a7050e01e
This takes 16 bytes off of the allocated size of each instance.
MozReview-Commit-ID: AhfN6MWvVL1
--HG--
extra : rebase_source : badc6ab690f2c4e0184ac0b51b29f81fb11279c6
extra : absorb_source : 0f685515a6946c89e9467c8b1e8548c989b1907b
extra : histedit_source : 7bfb5db39b23c1d262819c22a6e5fcd884c52504
We don't have a way to determine these at runtime, but for Windows and Linux,
the values are known and predictable.
MozReview-Commit-ID: 57LMJLzl762
--HG--
extra : rebase_source : 415690574116d549171097cb9e33834e4d4a9a4f
extra : absorb_source : 4678306b020999f52dcf770d3907d79f1f38b249
extra : histedit_source : 0d0f3cb62b9f64322876fe568ccd62893e6ad4b1%2Ccaca0524b930cf93608565ec06247aa0f4fee7e2
This adds reporting for heap overhead from nsThread and PRThread wrappers, as
well as thread event queues. It does not, currently, include overhead from
PlatformThread or js::Thread wrappers.
MozReview-Commit-ID: 6DkvbbkjHXm
--HG--
extra : rebase_source : 79df7172387fa1f952c43b06db644390be6f0d8a
This was moved out of nsThread in bug 1350432, but some dead code was left
behind.
MozReview-Commit-ID: BOhykHyIEPp
--HG--
extra : rebase_source : 21d4f95a019ba10851fba1efc588d6c2678aed85
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : rebase_source : 8d41a3fc5bc1ffe88af998bf9a0ba9ac3331a085
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : rebase_source : 57d151df64e29ee756f290e7eb047610b567ef04
The current code for resizing PLDHashTable modifies the cached hash for
all entries in the old hash table. This is unnecessary, because we're
going to throw away the old hash table shortly, and inefficient, because
writing to memory we're never going to use again just wastes time and
memory bandwidth. Instead, let's avoid the write by pulling out the
cached key and doing the necessary manipulation on local variables,
which is probably slightly faster.
This alters nsILoadURIDelegate.loadURI() to return a Promise rather than spinning the event loop to synchronously return a boolean, and alters nsDocShell::InternalLoad to allow for those changes by re-calling itself if necessary based on the resolution of the promise.
