Link's members are laid out like so:
mutable nsCOMPtr<nsIURI> mCachedURI;
Element * const mElement;
// Strong reference to History. The link has to unregister before History
// can disappear.
Besides this introducing 11 (!) bytes of padding on a 64-bit system, there's no need for mLinkState to be a full integer. nsLinkState only has a handful of values. mLinkState should be a PRUInt16 or similar; mRegistered could then be packed with it, which would save a word on 32-bit and 64-bit systems.
Created attachment 617105 [details] [diff] [review]
Comment on attachment 617105 [details] [diff] [review]
r=me. I wish compilers would get with the program and just let us declare the sizes of enums!
(In reply to Boris Zbarsky (:bz) from comment #2)
> r=me. I wish compilers would get with the program and just let us declare
> the sizes of enums!
If you're holding your breath to inject some sanity into any C++ compiler soon, be warned that you might need to hold it for way longer than recommended by the medical community. :-)
Nathan, thanks for filing this bug. :-)
We don't need sanity. We just need to drop gcc 4.2 on Mac and switch to clang with -std=c++0x. Well, and probably turn on c++0x mode in gcc on Linux too.
Nice patch! I had to use PRInt16 instead of a sized enum in bug 712865 as well.
What were the before and after sizes (on both 32-bit and 64-bit)? And roughly how many Link objects do we have live at a time?
It depends on the page. Basically, one per <a> or <link> or <area> element. So order of dozens to hundreds per page, though pathological cases could have tens of thousands on a page, of course.
(In reply to Nicholas Nethercote [:njn] from comment #6)
> Nice patch! I had to use PRInt16 instead of a sized enum in bug 712865 as
> What were the before and after sizes (on both 32-bit and 64-bit)? And
> roughly how many Link objects do we have live at a time?
This should save 4 bytes on 32-bit and 8 bytes on 64-bit per Link object.
> This should save 4 bytes on 32-bit and 8 bytes on 64-bit per Link object.
I should have guessed that from the bug title :) Thanks for clarifying!