Finding number 1:  There really was a change.  I composed a patch that enables only the required feature module visibility annotations, and applied it to both ToT and Tot 2 months ago (around the time prototype work was starting).  Then, a diagnose_bloat run at each point was run.  Drastically different results:

ToT at b8e3aa3e25a6:  +11,864 bytes main lib size
ToT at 88b4645c0f83:   +2,064 bytes main lib size

The patch differs at ToT, because VR code needs to have FEATURE_MODULE definitions renamed.  In both cases, changes to VR's exports were also removed, and FEATURE_MODULE and SKIA_DLL were defined for all files, leaving only the EXPORT macros in non-VR files having any effect.

Attaching two files - the 2 KB bloat from "then" (two months ago), and the 12 KB bloat from "now".

The question is now, what happened to bloat the export overhead?  Was a linker optimization enabled recently, and these visibility changes undo-some of the gains?

Deleted: diff_results_then.txt 102 KB

diff_results_then.txt 102 KB View Download

Deleted: diff_results_now.txt 458 KB

diff_results_now.txt 458 KB View Download

David, I previously spun a quick test build and I *think* I ruled out the ThinLTO enabling, but I'd want to verify more carefully.  Looking at the files, does anything come to mind over the last ~60 days that could have caused this?

Had a quick look at it, but no, nothing really comes to mind, sorry. The diffs shows that there are a lot more symbols, many of them seem unrelated (payement_processor?)

Looks like ThinLTO is indeed a factor, although seemingly not the only contributor:

b8e3aa3e25a6 (now):                        +11,864 bytes main lib size
b8e3aa3e25a6 (now, with ThinLTO disabled):  +6,148 bytes main lib size
88b4645c0f83 (8 weeks ago):                 +2,064 bytes main lib size

More detailed size numbers are here:

https://docs.google.com/spreadsheets/d/1YM1YeK78kXCFd6RepvuvFbc-y2JdNW8n-T1BfIMrHwc/edit?usp=sharing

ThinLTO is definitely a contributor, but not the only contributor.

The cause of the original increase is:

3b0e1ae53729 - Add ANGLE bindings for Skia <Jonathan Backer>

This is likely a case of the Skia module simply exporting many more symbols than before.  The prototype isn't using a proper export system for these symbols, it's piggybacking on SKIA_DLL.  If we properly export what's needed, we can probably get back down to the original overhead (or less).

Dropping in priority now that the sources are identified.

I want to run an experiment to see whether ThinLTO is still a contributor if we exclude Skia from the export list, at which point I'll close it off.

Correcting previous (deleted) comment:  By syncing back to before the Skia change, patching in the export system, and then patching in commit 3b0e1ae53729, I can get the breakdown of the binary size increase due to 3b0e1ae53729.

Unfortunately, most of the increase comes from this supersize entry:

~ 78)      4866 (117.8%) o@0x0        3335 (0->0)        {{no path}}
               Overhead: ELF file

Full diff file is attached.

Deleted: diff_results.txt 3.5 MB

diff_results.txt 3.5 MB View Download

Repurposing this bug to target minimzing the overhead of exporting Skia.

Note that at the time of the original change, when applying the linker whitelist, the total overhead of the SKIA change appears to reduce to ~30 bytes.

This bug is now obsolete, with the assembly-generated shim approach.