[CTW] Don't queue cache updates if we're never going to send them
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
Attachments
(1 file)
- We currently call QueueCacheUpdate in quite a few places, regardless of whether the cache is enabled or we're in a content process.
- QueueCacheUpdate then unconditionally tweaks the hash table, again regardless of these conditions.
- We only call ProcessQueuedCacheUpdates if the cache is enabled and we're in a content process.
The result is that when the cache is disabled and/or in parent process documents, we will have a bunch of stuff sitting in mQueuedCacheUpdates forever. It will just keep growing until the document is destroyed.
Rather than having conditions everywhere even for simple cases, I think QueueCacheUpdate should just return early if the cache isn't relevant.
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 1•2 years ago
|
||
This was wasting memory for the parent process, and when the cache was disabled, all content processes.
QueueCacheUpdate now checks whether we are actually sending cache updates before it queues anything.
Simple calls rely on this check, rather than guarding the call to QueueCacheUpdate themselves.
We still call QueueCacheUpdate conditionally for more complex cases which would have to do work before calling QueueCacheUpdate, since we don't want to pointlessly do that prerequisite work.
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59af8eea2123 Don't queue a11y cache updates if we're never going to send them. r=morgan
|
||
Comment 3•2 years ago
|
||
| bugherder | ||
Description
•