Closed Bug 1059056 Opened 5 years ago Closed 5 years ago
DOMAttribute Map::m Attribute Cache lazily
With Gmail, cnn.com and TechCrunch open, I have 1507 instances of nsDOMAttributeMap::mAttributeCache. 1504 of them are empty, and 3 of them have 1 element. On 64-bit, at 256 bytes a pop, their combined entry storage accounts for 385,792 bytes.
Comment on attachment 8479566 [details] [diff] [review] Instantiate nsDOMAttributeMap::mAttributeCache lazily This works, though we could also do a Maybe<AttrCache>, right? I guess that would still be bigger than a single pointer.... r=me
Attachment #8479566 - Flags: review?(bzbarsky) → review+
Just out of idle curiosity, about what % of the empty hash tables you were seeing was this responsible for, Nick?
> Just out of idle curiosity, about what % of the empty hash tables you were > seeing was this responsible for, Nick? About 50%.
Why isn't this using mozilla::UniquePtr instead of nsAutoPtr?
> Why isn't this using mozilla::UniquePtr instead of nsAutoPtr? I just wanted to give you a chance to ask "Why isn't this using mozilla::UniquePtr instead of nsAutoPtr?"
And I could ask why should it use mozilla::UniquePtr.
Try looks good: https://tbpl.mozilla.org/?tree=Try&rev=2e7a6d923050
(In reply to Olli Pettay [:smaug] from comment #8) > And I could ask why should it use mozilla::UniquePtr. Because nsAutoPtr is broken in the same ways std::auto_ptr is broken, in that it can sort-of be copied, and UniquePtr implements correct lack-of-copying semantics and proper move semantics. And also nsAutoPtr is non-standard, whereas UniquePtr emulates the standard std::unique_ptr interface, making it better for approachability/readability/understandability.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.