Thanks for bringing this up.

The most straight forward way to fix this is to introduce batching, where we can notify about multiple field trials in one IPC and have a time duration that the sender will wait to receive more messages before sending the IPC.

It does add a bit of complexity and I do wonder whether Mojo team has thought about doing this sort of optimization internally? (Or through a standard mechanism that a given Mojo client could configure?)

Adding rockot@ re: mojo question.

Hmm, we also see this even in the browser process though. I think batching from the field trials component independent of mojo could be an overall win

Yeah, sounds like something that should be solved at the application layer,
i.e. field trial mojom & impl.

I doubt there's a good batching policy we could impose internally that
would work for all use cases, so we shouldn't impose one at all.

The best I think we could do, just for the sake of completeness, would be
at a low level to support something like named batching groups to which
messages can be explicitly assigned, and an API to flush a batch by name.

Then the bindings could create a sequence-local batching group for every
sequence so that all sent messages are implicitly batched, and we could
flush every sequence's batch after every task run on that sequence (or
after any sync IPC is sent). This is a good bit of complexity for something
we could just address at the application layer when needed.

Do we have an UMA metric that would improve if we fix this?

If we're not tracking these types of problems in the wild and are not monitoring for regressions, then what's to say that any changes we do here won't just regress at some point?

If we have good metrics here, it would be easier to justify spending time to fix this.

Internal: https://docs.google.com/document/d/1sWsM9jt8mrWiN5ngfhVSgfHg2E_Kjls71dhYFI011rg/edit?disco=AAAABakPk4I&ts=5a003e6e

Random note: I saw this in the browser process on a recent trace.

mheikal: have you seen this in recent traces?
We do now also have uma metrics for startup, but it would probably be hard for small changes here to show up there.