Shrink bindings binary size by sharing code between similar attributes, methods, etc. |
|||||
Issue descriptionThere is an idea, apparently not new but recently discussed here <https://goto.google.com/cwlyo> (sorry, Google internal): Make the bindings generated code smaller by having "similar" attributes and properties (for some definition of similar, but maybe starting with having the same parameter types, return type, and extended attributes) share "code" (for some definition of code, but maybe starting with the things in gen/blink/bindings/core/v8 with names like x(AttributeGetter|AttributeSetter|Method) which take a v8::FunctionCallbackInfo, apply WebIDL JS binding rules, and thunk to Blink C++.) Some observations which might be useful are: - Link time de-duplication may make the problem not as bad as it seems. I (dominicc) found 3 MB of the 105 MB Chrome binary were in gen/bindings on a Linux x64 profiling release build, whereas agrieve found 1.5 MB of the supersizes Blink (bindings) category were in the MonochromePublic.apk recently. - If this has a negative runtime performance impact, "hot" bindings could opt out and all be "inlined." - We could do something more radical/compact and have a bindings JIT or interpreter which has very compact descriptions of marshaling instructions which it rolls over at runtime.
,
Aug 24 2017
If the thunks use ABI internals and tail call optimisation, it could be a net win for performance due to reduced cache contention, even on hot paths.
,
Aug 25 2017
,
Aug 25 2017
https://chromium-review.googlesource.com/#/c/633745/ is a rough sketch (narrowed to EventHandler, which is a common case with very similar bindings behaviour) based on my previous thinking about this. It yields about 4 kB of APK size savings (it was 12 kB before I fixed the correct plumbing of ExecutionContext per type, and tweaking how that is plumbed might recover a little of that). We can probably get a small multiplier (maybe 4-5x?) if we generalize this to other common bindings stubs, but this being much less than the ~1 MB cited as a goal discouraged me from following up on this last time I looked. Maybe a more radical approach would yield better gains? I haven't yet had a chance to exhaustively study the performance. Many (but not all) of the calls end up getting tail calls, which is nice. :)
,
May 3 2018
,
May 25 2018
,
Aug 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dominicc@chromium.org
, Aug 24 2017