Some questions about Profile guided function order via Temporal Profiling, such as binary size regression

[ellishg]

@dreampiggy

From the result, the binary size increment nearly all comes from the increased branch island.

This is interesting. I’ll have to check to see if our apps show similar regressions, but I suspect not because I don’t remember large uncompressed __text size regressions.

@dreampiggy

From your suggestion, I even use objdump -h to compare the binary itself. Here is the result. Ignore the VM address changes, only care about size

I see that the __unwind_info section significantly reduced, and I also observed this. In fact, I’ve locally added new hashes to represent the unwind info type for each function to further improve the uncompressed __unwind_info size. When I get the time I want to submit a PR for this, so I’m glad to see you observe this too.

@dreampiggy

Another question: The whole MachO section size diff is 1.71MB, but the binary size diff is 2.05MB, but I don’t know why there are 340KB loss ? Any practice to compare the binary MachO size layout.

Bloaty is a nice tool to compare binaries.

GitHub - google/bloaty: Bloaty: a size profiler for binaries

I’m not exactly sure what you mean though. Are you saying that the accumulated diff of the sections (1.71MB) do not match the diff of the binaries (2.05MB)?