Thanks for filing, I'm going to look into this a bit to at least get some size estimates. (Or maybe someone's already done that?)

tibell@ has already looked at this quite a bit and may have useful information persisted somewhere.

A bug that is relevant:  crbug.com/597125 
"Measure binary size impact of Mojo vs. Chrome-IPC"

I tried to remove all validation code and see what the upper bound of gain would be. That saved ~450K. Please see comment #31 in that bug.

Johan probably have more useful info to share.

Thanks! I'll try to understand the data in that bug next.

I was thinking of trying to drop all validation too, so good to know how much that saves.

When looking through the generated code, it seems like Serialize, Deserialize, and Validate are all performing more or less the same thing. I'm totally oversimplifying, but they're basically walking the structs and fields recursively and then doing one of those Serialize, Deserialize, or Validate. Do you think there's a possibility to collapse them to use utility functions that operate on a (hopefully smaller) description of the structures and incoming/outgoing data?

I looked at one (trivial) message and logged some data on it here:
https://docs.google.com/document/d/1TlEoPNOH2a_AjYjcU8-sCftYotJLCJpES-Jzf3QEYiU/edit?usp=sharing

> When looking through the generated code, it seems like Serialize, Deserialize, and Validate are
> all performing more or less the same thing. I'm totally oversimplifying, but they're basically 
> walking the structs and fields recursively and then doing one of those Serialize, Deserialize, or 
> Validate. Do you think there's a possibility to collapse them to use utility functions that 
> operate on a (hopefully smaller) description of the structures and incoming/outgoing data?

I think that is possible. But I am not sure how much that would gain us. Given that removing validation code of all mojom interfaces currently built into chrome reduces ~450K, I would guess that we would save a few hundred KBs at best.

Some quick experiment would be nice to give a rough idea.

regarding binary size estimates, note we still have a lot of old IPC files. I haven't measured the number of old IPCs vs existing mojo methods, but that could give a rough estimate of how more savings we can get from sharing the validation & seriailzation code.

That makes sense.

Sorry, comment #5 probably sounds like I am suggesting that it doesn't worth the effort to explore this approach. I think it is a good thing to try out. Just tried to give a wild-ass guess that the gain may be of the same order of magnitude as removing all validation code.

Thanks. It does seem hard to get a good estimate of size impact due to heavy template use.

As Johan noted in  crbug.com/597125  (and already improved on) there's a lot of code going to peripheral template expansion (like InterfacePtr). I also noticed quite a bit generated by AssociatedBinding.

These aren't directly due to the generated code or specifically what this bug is about, but just how we've set up bindings more generally. I wonder if we could work at removing a big chunk of that also.

WRT AssociatedBinding, it might be useful to extract a non-template base class. Something like:
https://codesearch.chromium.org/chromium/src/mojo/public/cpp/bindings/lib/binding_state.h?rcl=f2d23ac6b62b2e0560bd756bc22e4ab0d66fe8eb&l=36

Corresponding CL by Johan:
https://chromium.googlesource.com/chromium/src/+/ad0c0b3bab4a19dfafb51bda1dad56024c2dc9e2

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/83392e9f4312a231f60c5d2b8f0bfa4f80aa92cd

commit 83392e9f4312a231f60c5d2b8f0bfa4f80aa92cd
Author: scottmg <scottmg@chromium.org>
Date: Thu Feb 09 18:46:45 2017

Reduce size of mojo AssociatedBinding template expansions

In particular for AssociatedBinding::Bind(), reduces expansion to 54% of
original size on Windows.

This only saves about 4K on the final libchrome.so size on Android, so
not a huge win, but: 1) it doesn't add much complexity to the
implementation, and 2) I think it'll be useful to do more followups that
de-type bindings code.

R=yzshen@chromium.org
BUG= 597125 ,689690

Review-Url: https://codereview.chromium.org/2680243003
Cr-Commit-Position: refs/heads/master@{#449364}

[modify] https://crrev.com/83392e9f4312a231f60c5d2b8f0bfa4f80aa92cd/mojo/public/cpp/bindings/BUILD.gn
[modify] https://crrev.com/83392e9f4312a231f60c5d2b8f0bfa4f80aa92cd/mojo/public/cpp/bindings/associated_binding.h
[add] https://crrev.com/83392e9f4312a231f60c5d2b8f0bfa4f80aa92cd/mojo/public/cpp/bindings/lib/associated_binding.cc

Short-ish update, I haven't had a chance to write code against this, so only more talking sadly.

I do think there's an opportunity to improve both size of bindings and perhaps the performance. (Some of my optimism may be due to not being involved in previous development though, so I may be lacking context on requirements.)

The two things I'd like to try first:

1) have the high-level C++ bindings based on a low-level table driven encoder/decoder (I think this can save code size)

2) encourage more in-place encoding and decoding (which I think could improve perf too)

As an example for #1:

https://cs.chromium.org/chromium/src/out/Debug/gen/content/common/image_downloader/image_downloader.mojom-shared.cc?type=cs&q=ImageDownloader_DownloadImage_ResponseParams_Data::Validate+package:%5Echromium$&l=80

compiles to 378 bytes on Win x64 Release (not counting the templated functions that do container validation of the array<Bitmap> and array<Size>).

I expect the equivalent table-based validation to require one word per field (maybe plus a header). There's 3 in this message response, so I'd expect ~32 bytes.


On #2 the in-place-ness, using the same example, we validate on a view of the Message which is good, but then convert to native types (e.g. std::vector<> or WebVector<> depending on which way it's going). After eliding template goop, the stack looks like this when we get back to "real" code:

    content.dll!content::WebContentsImpl::OnDidDownloadImage(...) Line 5126
... callback goop ...
    content.dll!content::mojom::ImageDownloader_DownloadImage_ForwardToCallback::Accept(mojo::Message * message) Line 78
... accept/validate goop ...
    bindings.dll!mojo::Connector::ReadSingleMessage(unsigned int * read_result) Line 258

That is, the message data is still sitting on the stack in a Message buffer. If consumers and producers were more mojo-y, they could just use the data sitting in that buffer, rather than copying it out to different types. The types in a message are necessarily "data"-ish types, not "object"-ish types, so this seems reasonable. I think this would both reduce code size due to minimizing template instantations and be faster due to less copying.


All that said, I'm not sure how urgent this is vs. just a preference thing, because as Yuzhu outlined, validation only accounts for a maximum of 454k of code per  crbug.com/597125#c31 . I redid that size comparison with the same test cl today (crrev.com/2491583004), and now it's up to 582k. So it grew by 22% in ~4 months, which isn't excellent, but maybe not our biggest problem either.

I started a sketch of the low-level api I was thinking of. It's not super-interesting or detailed, pretty much just what you'd expect: https://docs.google.com/a/chromium.org/document/d/1aYCF-yabSBRdrw3itpeUDnf-GZVX3HAoZqOYVK4EV1s/edit?usp=sharing . If no one thinks it's the worst idea ever, I'll try implementing that, perhaps starting small by replacing only the struct ::Validate()s like the ImageDownloader_DownloadImage_ResponseParams_Data::Validate() linked above.

A few quick comments before I look at the design doc more carefully.

RE #1: It would be nice to get some perf numbers comparing the current approach and the table-driven one before starting conversion.

RE #2: We already support the *DataView classes which are views into the message buffer. However, those types are not always what the receiver would like to use. For example, the user would like to receive a GURL object as argument, instead of a url::mojom::URLDataView. StructTraits<url::mojom::URLDataView, GURL> does customized validation before giving the object to the user code. It is nice that we do that automatically/consistently for the user.

WDYT? Thanks!

Thanks for looking!

Re #1, sure of course. Is there a particular perf test/suite that would be useful for this?

I'm less certain on #2. I guess in some cases it's really a lot nicer to copy into a "big" type with various methods like GURL, but I feel like there's also cases where it's a mostly unnecessary copy, and a receiver could equally well be changed to used DataViews instead. Perhaps we could extend DataViews to give them interfaces closer to the types to which they'd otherwise be converted too? Anyhow, thanks for the context, I'll leave #2 alone for now, as it's more far-reaching.

> Re #1, sure of course. Is there a particular perf test/suite that would be useful for this?

I used to use cc_serialization_perftest.cc to measure impact of my changes to validation/serialization code because it tests some fairly complex data structures (which are also used in production code). We could consider adding more tests as well.

Re #1: We discussed this during a Mojo meeting. I think it's the way to go if code size gets problematic enough to warrant it. From my experience working on protocol buffers I'd expect that a table-driven encoder/decoder would be >10x slower than a well-written generated one. That might still be fast enough (and the current encoder/decoders we generate aren't as fast as they could be.)

We could also try to do some halfway thing where lots of the dispatching logic (e.g. the generated Accept functions, callback adapters, etc) are shared and table-driven, but where the actual encoders/decoders are still generated.

In terms of importance, it's current the case that many fairly straight-forward commits that add new mojo bindings trigger the Android code size bloat warning. Latest example is bug 703114. Getting some concrete reductions on mojo code size would hopefully alleviate these perf alerts.

I prototyped what I typed up in the document above, and I think it could work. But I'm afraid so far I've been overwhelmed by the rest of the complexity around bindings so I don't have anything that I can land that will help on Android.

If anyone else feels motivated, feel free to take a stab/this bug.

> I'm less certain on #2. I guess in some cases it's really a lot nicer to copy into a "big"
> type with various methods like GURL, but I feel like there's also cases where it's a mostly
> unnecessary copy, and a receiver could equally well be changed to used DataViews instead.
> Perhaps we could extend DataViews to give them interfaces closer to the types to which they'd
> otherwise be converted too? Anyhow, thanks for the context, I'll leave #2 alone for now, as
> it's more far-reaching.

It's not currently possible to validate mojo structs if they don't go through StructTraits: see issue 651711. The basic validations in the mojom syntax itself are useful but not sufficient. From a security perspective, that blocks a move towards using raw mojo types more.

Using a release build on Linux, I found the use of TRACE_EVENT0 macros in generators/cpp_templates/interface_definition.tmpl account for roughly half of the generated code size of the various FooStubDispatch::Accept functions.

Looking at blink::mojom::WebSocketClientStubDispatch::Accept, it went from 4436 bytes down to 2295 bytes simply by commenting out the TRACE_EVENT0 lines. Hmm...

If memory serves correctly, one of the tracing symbols showed up on the top 20 inlined things in Chrome. I didn't have time to investigate further at the time (since it was "only" 300 KB), but it seemed like there might be opportunities for shrinking that.

I tried building chrome before/after removing the TRACE_EVENT0s in interface_definition.tmpl:

Linux official builds of chrome (stripped):
before: 134459720
after: 134201672  (-258048)

It is a pretty significant difference.

I thought Johan had previously looked at this and determined that tracing wasn't a significant factor, but I might be wrong. Maybe the macros have become more expensive in the past N months? That is indeed quite a difference in size.

I did indeed look into this once, with the goal of making the inlined code for that macro (and related ones) smaller for all of Chrome. I didn't try to eliminate the uses in Mojo (I thought they were valuable). I measured the effect to be 200kb or so across all of Chrome (i.e. 200kb from all uses of the macros, not just Mojo). Perhaps increased use of Mojo has made this more valuable.

fyi: there is a proposal to reduce the binary size impact of tracing macros: issue 708990

We already plumb through a per-interface heap profiler tag to the non-templated message dispatch code in SimpleWatcher, and since this is even attached to deferred tasks it's strictly more useful than a TRACE_EVENT inside the generated code.

We should just delete these macro invocations.

Oops, I take that back. The TRACE_EVENTs in generated code are of course useful... they are obviously invoked during deserialization and dispatch, not before.

Still, interface-level granularity may be sufficient for now and we can easily kill ~250 kB in the meantime.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/58ef78ca2ffaba94473a22809c619cb96d576eea

commit 58ef78ca2ffaba94473a22809c619cb96d576eea
Author: Ken Rockot <rockot@chromium.org>
Date: Mon May 22 18:35:42 2017

Mojo C++ bindings: Avoid per-message trace events in generated code

Removes TRACE_EVENT0 invocations from generated per-message dispatch
code, in favor of a less granular TRACE_EVENT0 inside the internal
Connector which has only the master interface name for the relevant
message pipe.

This should substantially reduce binary size (expected ~250 kB
decrease) at the risk of making Mojom tracing slightly less useful.

BUG=689690
R=yzshen@chromium.org

Change-Id: Iceb72137c8b4711dad6eb344409c4c156d7bf8ea
Reviewed-on: https://chromium-review.googlesource.com/510703
Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#473634}
[modify] https://crrev.com/58ef78ca2ffaba94473a22809c619cb96d576eea/mojo/public/cpp/bindings/connector.h
[modify] https://crrev.com/58ef78ca2ffaba94473a22809c619cb96d576eea/mojo/public/cpp/bindings/lib/connector.cc
[modify] https://crrev.com/58ef78ca2ffaba94473a22809c619cb96d576eea/mojo/public/tools/bindings/generators/cpp_templates/interface_definition.tmpl
[modify] https://crrev.com/58ef78ca2ffaba94473a22809c619cb96d576eea/mojo/public/tools/bindings/generators/cpp_templates/module.cc.tmpl

I completely forgot I had landed r473634!

Just to follow up from this, that revision resulted in a 112 kB reduction in MonochromePublic.apk_Specifics/normalized apk size: https://chromeperf.appspot.com/report?sid=d8f7a27ce61034755ba926dfff9beff7dfbee6f8a596da7f4bb80e3bdd721ad4&start_rev=473534&end_rev=473734

So that was indeed a significant chunk of the generated code size.

While doing an audit of string literals in our binary ( bug 778067 ), I noticed that there are many that look like: 
  "null replication_state field in Renderer_CreateFrameProxy_Params"

Turns out that these are from mojo validation code.

Nulling out these strings saves 160kb
What I tried: https://chromium-review.googlesource.com/c/chromium/src/+/738397

Refactoring to use more smaller strings saves a much more modest 45kb
What I tried: https://chromium-review.googlesource.com/#/c/chromium/src/+/738398

Note that generated mojo bindings now accounts for 1.3MB of our libchrome.so:
https://agrieve.github.io/chrome/supersize-chrome-android-oct-19-2017/console.txt

How important is it to have these nice error messages for null fields? Could we change these to be enabled only for debug builds?

We do capture these strings in a crash key and they are useful, but it may
in fact not be necessary to have so much detail.

I assume the thing that's really killing us (given the remaining 115 kB
with your refactoring) is just having the names of every struct and field.
If we replace the field name with the ordinal value of the field and omit
the struct name entirely, I think that information combined with the stack
trace should be sufficient.

I need to make a change to how we generate crash reports for bad messages
from non-renderer processes in order to improve stack quality there, but
that's not something I would block this on.

If we could view the source code of the generated mojom.{h,cc} files in crash reports, we don't even need ordinal number.

(+Internal>CrashReporting so that some crash experts might chime in.)

I don't think the generated code should be special as far as source indexing goes (at least for Windows). Do you happen to have a crash link handy that should be displaying generated mojom but isn't?

Scott:
This is one of the result I searched "::mojom::" on crash/
https://crash.corp.google.com/browse?q=&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=::mojom::&reportid=60f67379a7c369f1&index=0#4

The link about is a webview crash.

This one is a windows crash:
https://crash.corp.google.com/browse?q=&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=::mojom::&reportid=464af4053f3b7b51&index=7#4

Sorry, I was mistaken. +Seb corrected me; source indexing needs somewhere to retrieve the files from (of course), but the generated files aren't archived so there's no way that to work at the moment.

I don't know mojo well enough to have followed the conversation, so want to clarify #35. Would logging object_name & field_index be what we want? 

Is object_name in the stack trace anyways (e.g. from #39: "blink::mojom::WebSocketStubDispatch"), or are there nested objects that don't appear?

Is it important to log which field was wrong, or is it just as meaningful to say "the struct was corrupt"?

It's useful but not necessary to log which field was wrong, and yes,
field_index would be sufficient instead of field name. The object name is
unnecessary to log because it's in the stack trace.

Does it make sense to add support to the crash server to view the source of generated mojom.{h,cc} file instead of adding field_index?

Before that is done, if we really need the field information we could locally generate the right revision of mojom.{h,cc}, and use the corresponding source line position from crash report to identify which field it is.

Indexing generated sources would be great for more than just this too, only
problem is I'm not sure how much work it would take to get done. Including
field index for now avoids that issue in a simple way while still cutting
out the extra strings, so it might be a reasonable way to start.

Okay. Seems fine to me. Just thinking that maybe we could save a little bit of work which ideally would be removed after adding support of indexing mojom.{h,cc}.

I'm not really familiar with mojo's generated files etc so it's hard for me to make suggestions on how to improve the indexing for these. 

First, there's 2 kind of source-indexing in Chrome (only talking about Windows here):
- on the crash server: we generate the breakpad symbols for the binaries we're interested in and we push them to the crash server, then the crash UI uses some tricks to get the source-code available in the crash UI.
- on the developer/debuggers machine: We source-index the PDBs and we push them to the public symbol server.

I'll only talk about the source-indexing of the PDB here because I'm not familiar enough with how things get done on the crash server, using breadcrumbs might be a good way to add some annotations there.

The source-indexing step does the following things:
- It start by listing all the source files used to build the binary.
- For each of these source files it checks if this files comes from a git repo, if not the file gets ignored (this is where we drop the generated files).
- for each of the files coming from a Git repo it adds an entry to a table that do the mapping {source_file} -> {url to retrieve this file}.

So when you try to access a source file in Windbg it (kinda) simply does a wget on this url to retrieve the file.

This means that if you want source-indexing for the generated file then you'll need to have them archived somewhere so Windbg can fetch them.

There's some other ways to fix this but none will be perfect, e.g. for these files we could try to check on the developer machine if there's a similar file available.

If you do think that this will be really important to get source-indexing for these files then we should consider adding a build-step that archive the gen/ folder to a (public?) gs bucket, assuming there's nothing confidential in these files.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513

commit 9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513
Author: Andrew Grieve <agrieve@chromium.org>
Date: Fri Oct 27 18:43:51 2017

Mojo: Show only field index in mojo ValidateNonNull() errors

Used to show object_name and field_name. However, object_name
can be found by looking at stack trace, and field_index is 
enough that you can look up which field it is.

Shrinks android binary by 160kb: .text=-56.1kb .rodata=-106kb

The .text reduction comes from more functions being
identical-code-folded.

Bug: 689690, 778067 
Change-Id: I9090e486935ad391d6c258d67278c352e36ea5c0
Reviewed-on: https://chromium-review.googlesource.com/738398
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512253}
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/cpp/bindings/lib/map_data_internal.h
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/cpp/bindings/lib/message_header_validator.cc
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/cpp/bindings/lib/validation_util.cc
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/cpp/bindings/lib/validation_util.h
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/tools/bindings/generators/cpp_templates/struct_definition.tmpl
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/tools/bindings/generators/cpp_templates/union_definition.tmpl
[modify] https://crrev.com/9b4ca2e65d1efc2a7f4168dadb3f207c0cfc0513/mojo/public/tools/bindings/generators/cpp_templates/validation_macros.tmpl

RE #46: Thanks Sébastien for the information.

It sounds there is some work to figure out how to get that working. Then I don't have a strong opinion whether we should add support for generated file indexing, if the only purpose is to easily find out the exact field that is being validated.

Another offender: c02aba509ea2b2d322758982f52739a2dcf09fa0
"Turn on lazy serialization for network service interfaces."

All it did was add support_lazy_serialization = true to a mojom, and increased android arm32 by 20kb. Supersize diff looks like:

Section Legend: t=.text, r=.rodata, R=.data.rel.ro, d=.data, b=.bss, p=.pak.translations, P=.pak.nontranslated, o=.other
Index | Running Total | Section@Address | Δ PSS (Δ size_without_padding) | Path
------------------------------------------------------------
~ 0)       1156 (5.7%)  o@0x0        1156 (2644->3800)  {{no path}}
               ELF file overhead
~ 1)       2014 (10.0%) t@Group      858 (0->0)         {{no path}}
               ** symbol gaps (count=9)
~ 2)       2634 (13.0%) t@0x9fb774   620 (796->1416)    services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerStubDispatch::AcceptWithResponder
~ 3)       3154 (15.6%) t@0xa00640   520 (908->1428)    services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderClientStubDispatch::Accept
+ 4)       3552 (17.6%) t@0xa01dba   398 (0->398)       services/network/public/interfaces/url_loader_factory.mojom.cc
               network::mojom::URLLoaderFactoryProxy_CreateLoaderAndStart_Message::Build
+ 5)       3898 (19.3%) t@0x13a5e3a  346 (0->346)       services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc
               network::mojom::blink::RestrictedCookieManagerProxy_SetCanonicalCookie_Message::Build
+ 6)       4242 (21.0%) t@0x13a5c28  344 (0->344)       services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc
               network::mojom::blink::RestrictedCookieManagerProxy_GetAllForUrl_Message::Build
+ 7)       4558 (22.5%) t@0x9ffc5a   316 (0->316)       services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderClientProxy_OnReceiveResponse_Message::Build
+ 8)       4868 (24.1%) t@0x9fa8ba   310 (0->310)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerProxy_RequestNotification_Message::Build
~ 9)       5172 (25.6%) t@0x9ff750   304 (292->596)     services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderStubDispatch::Accept
~ 10)      5468 (27.0%) t@0x9fead0   296 (588->884)     services/network/public/interfaces/restricted_cookie_manager.mojom.cc
               network::mojom::RestrictedCookieManagerStubDispatch::AcceptWithResponder
+ 11)      5728 (28.3%) t@0x9ffdce   260 (0->260)       services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderClientProxy_OnReceiveRedirect_Message::Build
+ 12)      5986 (29.6%) t@0x9fa422   258 (0->258)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerProxy_GetCookieList_Message::Build
+ 13)      6226 (30.8%) t@0x9fa5b6   240 (0->240)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerProxy_SetCanonicalCookie_Message::Build
~ 14)      6446 (31.9%) t@0x9fb380   220 (480->700)     services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerStubDispatch::Accept
+ 15)      6666 (33.0%) t@0xa0253a   220 (0->220)       services/network/public/interfaces/url_loader_factory.mojom.cc
               network::mojom::URLLoaderFactoryProxy_CreateLoaderAndStart_Message::Serialize
+ 16)      6884 (34.0%) t@0x9fa746   218 (0->218)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManagerProxy_DeleteCookies_Message::Build
+ 17)      7102 (35.1%) t@0x9fad38   218 (0->218)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManager_GetAllCookies_Response_Message::Build
+ 18)      7320 (36.2%) t@0x9faf52   218 (0->218)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieManager_GetCookieList_Response_Message::Build
+ 19)      7538 (37.3%) t@0x9fe90e   218 (0->218)       services/network/public/interfaces/restricted_cookie_manager.mojom.cc
               network::mojom::RestrictedCookieManager_GetAllForUrl_Response_Message::Build
+ 20)      7756 (38.4%) t@0xa00134   218 (0->218)       services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderClientProxy_OnReceiveCachedMetadata_Message::Build
+ 21)      7964 (39.4%) t@0x9fa1c4   208 (0->208)       services/network/public/interfaces/cookie_manager.mojom.cc
               network::mojom::CookieChangeNotificationProxy_OnCookieChanged_Message::Build
+ 22)      8172 (40.4%) t@0x13a6332  208 (0->208)       services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc
               network::mojom::blink::RestrictedCookieManagerProxy_GetAllForUrl_Message::Serialize
+ 23)      8380 (41.4%) t@0x13a64fa  208 (0->208)       services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc
               network::mojom::blink::RestrictedCookieManagerProxy_SetCanonicalCookie_Message::Serialize
+ 24)      8578 (42.4%) t@0x9fe1dc   198 (0->198)       services/network/public/interfaces/proxy_config.mojom.cc
               network::mojom::ProxyConfigClientProxy_OnProxyConfigUpdated_Message::Build
+ 25)      8776 (43.4%) t@0xa00400   198 (0->198)       services/network/public/interfaces/url_loader.mojom.cc
               network::mojom::URLLoaderClientProxy_OnComplete_Message::Build
~ 26)      8584 (42.5%) t@0x13a5db4  -192 (326->134)    services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc
               network::mojom::blink::RestrictedCookieManagerProxy::SetCanonicalCookie
~ 27)      8398 (41.5%) t@0x13a5b9c  -186 (326->140)    services/network/public/interfaces/restricted_cookie_manager.mojom-blink.cc

Yes, this is why lazy serialization is optional. It generates extra code
for better performance in intraprocess mesaging.

20 kB seems pretty large for this target. We can probably be more selective
about the mojoms it applies to.