Sending MessageManager messages is expensive, but a lot of the overhead is
per-message more than it's tied to the complexity of the message. In
particular:
- Each sendAsyncMessage call incurs separate XPConnect method call overhead.
- Each message requires acquiring a lock, and separate message setup overhead
for IPC.
- The message data itself must be structured cloned, which requires
(expensive) allocation of buffers to hold the serialized data. Each buffer
segment is 4KB, which is generally enough to hold multiple serialized
messages, so coalescing messages means fewer buffer allocations.
Moving some of this work into idle slices also means less likelihood of
interfering with UI responsiveness.
MozReview-Commit-ID: 5SAMZNLVaY3
Currently if there is no default icon at the specified size, the default icon
falls back to the light text icon at that size. This is wrong in two ways:
First, the default theme uses dark text, so it should fallback to the dark icon
Secondly, authors expect the unsized default_icon to be used if specified
This patch fixes both of these issues, so that the default icon first falls back
to the unsized default_icon, and then only if that is not specified falls back
to the dark icon
MozReview-Commit-ID: C3RRTKhYq6r
It turns out that stringifying a paths object is much cheaper than normalizing
it, and has the added benefit of allowing us to use cached CSS text for the
result.
MozReview-Commit-ID: 5gIqcDmPiKr
checkLoadURIStrWithPrincipal runs URLs through the URI fixup services and
checks against each of the results. This is both expensive and unnecessary for
our purposes.
MozReview-Commit-ID: 4L2Z4KuMZhQ
Web contetnt processes only need access to a small amount of schema data, but
we currently send them the approximately 600K of full schema data that is
mostly useless to them.
This patch limits the schema data sent to web content processes to what they
actually need, and sends the rest only to extension content processes.
MozReview-Commit-ID: 6G0LThNTOu1
This performs main thread IO to make sure that directories exist, which is not
something we should be doing on the startup path.
MozReview-Commit-ID: 2NrgRgY5ua6
Reading the extension permissions DB at startup takes several hundred
milliseconds, largely from the overhead of initializing OS.File. We can avoid
that somewhat by using the stream APIs to read the files, and beginning the
read very early. But the eager initialization gets complicated, and we still
add extra IO to startup.
After this change, the permissions JSON file still remains the primary source
of truth, but the state as of the last session is cached in the volatile
extension startup cache to decrease the overhead of reading it at startup.
MozReview-Commit-ID: HGDt5kSsdzX
IndexedDB helped where we needed to decrease main thread CPU, but it also took
so long to inialize during startup (over 500ms on a fast machine) that it
delayed extension startup more than was acceptable.
Using a structured clone flat file solves the same issues that IndexedDB did,
but with much less startup overhead.
MozReview-Commit-ID: 1Of7uxKCfkg
This gives us performance wins in sevaral areas:
- Creating a structured clone blob of storage data directly from the source
compartment allows us to avoid X-ray and JSON serialization overhead when
storing new values.
- Storing the intermediate StructuredCloneBlob, rather than JSON values,
in-memory saves us additional JSON and structured clone overhead when
passing the values to listeners and API callers, and saves us a fair amount
of memory to boot.
- Serializing storage values before sending them over a message manager allows
us to deserialize them directly into an extension scope on the other side,
saving us a lot of additional structured clone overhead and intermediate
garbage generation.
- Using JSONFile.jsm for storage lets us consolidate multiple storage file
write operations, rather than performing a separate JSON serialization for
each individual storage write.
- Additionally, this paves the way for us to transition to IndexedDB as a
storage backend, with full support for arbitrary structured-clone-compatible
data structures.
MozReview-Commit-ID: JiRE7EFMYxn
This gives us performance wins in sevaral areas:
- Creating a structured clone blob of storage data directly from the source
compartment allows us to avoid X-ray and JSON serialization overhead when
storing new values.
- Storing the intermediate StructuredCloneBlob, rather than JSON values,
in-memory saves us additional JSON and structured clone overhead when
passing the values to listeners and API callers, and saves us a fair amount
of memory to boot.
- Serializing storage values before sending them over a message manager allows
us to deserialize them directly into an extension scope on the other side,
saving us a lot of additional structured clone overhead and intermediate
garbage generation.
- Using JSONFile.jsm for storage lets us consolidate multiple storage file
write operations, rather than performing a separate JSON serialization for
each individual storage write.
- Additionally, this paves the way for us to transition to IndexedDB as a
storage backend, with full support for arbitrary structured-clone-compatible
data structures.
MozReview-Commit-ID: JiRE7EFMYxn
The code that saves the pending browser across an asynchronous
API load was accidentally broken as a result of some overzelous
cleanup. Fix it here.
MozReview-Commit-ID: 3ED95YJAHL2
The implementations of browserAction, pageAction, and menu onClick
handlers now stash the current <browser> until we get a reply from
the extension process indicating that the handler has finished running.
We also have to take care to keep that <browser> around even if the
permissions api has to be loaded asynchronously.
MozReview-Commit-ID: BYJaiwdj40u
The implementations of browserAction, pageAction, and menu onClick
handlers now stash the current <browser> until we get a reply from
the extension process indicating that the handler has finished running.
We also have to take care to keep that <browser> around even if the
permissions api has to be loaded asynchronously.
MozReview-Commit-ID: BYJaiwdj40u
