Unreasonable TrichromeLibrary64.apk size increase

[TAMURA, Kent]

Hi,

https://chromium-review.googlesource.com/c/chromium/src/+/5534801/5

This small change fails on Chromium Binary Size bot.

Name	Size Delta	Limit	Status
Android Binary Size	-160 bytes	+16,384 bytes	Allowed
Android Binary Size (arm64 high end) (TrichromeLibrary64.apk)	+113,628 bytes	+65,536 bytes	Not Allowed

It seems calling InlineBreakToken::RubyData() caused this increase. InlineBreakToken::RubyData() has never been used until this CL and probably the implementation of InlineBreakToken::RubyData() is dropped without the CL.  However the increased size looks unreasonable, and I have no idea how to avoid this.

Is it ok to suppress this failure by Binary-Size: ?

--

TAMURA Kent
Software Engineer, Google

[Andrew Grieve]

Pretty strange that this would have ~zero size effect on ARM32, yet a large size effect on ARM64.

I created a local size report for your CL here: https://chrome-supersize.firebaseapp.com/viewer.html?load_url=https%3A%2F%2Fstorage.googleapis.com%2Fchrome-supersize%2Fprivate-oneoffs%2F5d5e024b1f618d60c3a0efe205884e507c6c51c0_fbd24b4c2373d35d0731ac5f353a5b64da4d4854.sizediff#focus=41

It appears the entire size is going into LineBreaker::NextLine()

My best guess is that there is some inlining / loop unrolling / vectorization going on due to the -O2 vs -Os difference. If this is hot code, maybe it's justified? It might go away with a NO_INLINE somewhere, but it's not worth spending more than ~an hour on (as I think it's also likely that toolchain changes could make this go away on its own at some point)

--
You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/CAGH7WqGYdHEwRjv4V_04S4FmF_vE3uyPyb1MuSRmx-7WO8BRpQ%40mail.gmail.com.

[TAMURA, Kent]

Wow, I didn't know the -O2 vs -Os difference.  Keeping a small binary without size-optimization is challenging!

The size report is very helpful.  Adding NOINLINE to LineBreaker::HandleRuby() seems to work well.  Thanks for your help!

[Andrew Grieve]

Awesome!