This forces us to have hacks in the stylo bindings to deal with debug and release builds having different used template parameters, and seems that it could be a win if we plan to make use of `final` refcounting methods in stuff like nsIAtom, which the compiler should be able to devirtualize. Nathan told me that this feature existed mainly because of codesize reasons, so I did two try runs, one with it enabled, and one with it disabled, and here are the results: Feature enabled: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbc5476d904d72018eeb71be09fd73bdbe5728d4 ======== Size of libxul.so: Linux PGO: 100218064 bytes Linux x64 PGO: 104317992 bytes Android 4.0 API15+: 21845876 bytes Android 4.2 x86: 21846756 bytes Size of target zip: Windows 2012 PGO: 52252651 bytes Windows 2012 x64 PGO: TBD, build failed intermittently Disabled: https://treeherder.mozilla.org/#/jobs?repo=try&revision=100b9856c6aee244feff223c61c2d6fe7250e8ab ========= Size of libxul.so: Linux PGO: 100498568 bytes Linux x64 PGO: 104541808 bytes Android 4.0 API15+: 21881812 bytes Android 4.2 x86: 21946704 bytes Size of target zip: Windows 2012 PGO: 52287201 bytes Windows 2012 x64 PGO: 56194506 bytes
Looks like the biggest regression is ~220kb in size in linux. It doesn't look like a lot to me, but I'm not an expert in this kind of stuff. Nathan, do you know if that's an acceptable price to pay?
(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > Looks like the biggest regression is ~220kb in size in linux. It doesn't > look like a lot to me, but I'm not an expert in this kind of stuff. Nathan, > do you know if that's an acceptable price to pay? 220KB is quite a lot... Can you measure instead the real binary sizes of libxul on different platforms? e.g. for Linux, for my running firefox, I get: froydnj@hawkeye:~/src/gecko-dev.git$ ls -l ~/firefox/libxul.so -rwxr-xr-x 1 froydnj froydnj 104324592 Apr 28 13:57 /home/froydnj/firefox/libxul.so froydnj@hawkeye:~/src/gecko-dev.git$ size !!$ size ~/firefox/libxul.so text data bss dec hex filename 67543261 5361648 421424 73326333 45edefd /home/froydnj/firefox/libxul.so The size of the text section is what we're interested in, since that's the best representation we have of how much code size increased. (If you're so inclined, you could do `readelf -SW libxul.so |grep text` for an actual measurement of just the code.) `size` might not do the right thing on Android, because we use special compression techniques there, but it is at least worth examining. `dumpbin` is probably what you want on Windows for measuring xul.dll.
You need to log in before you can comment on or make changes to this bug.