+holte@

I think it may make sense add something for sending data in batches.  I think this is probably less important than for UMA since the UKM data is not aggregated on the client, so this is mainly a number of calls thing.  I think in some cases, we might need to be careful about how process shutdown is handled, and we may need to have some analog of PersistentHistograms to store data until it has been received by the UkmService.

Sorry, what do you mean when you say the UKM data is not aggregated on the client? Is there a reason we can't make a UkmRecorder implementation that aggregates data from the clients, and then have the UkmService pull it - similar to how UMA works?

I mean that if you have some UMA histogram like
UMA_HISTOGRAM_COUNTS("XYZ", value), and you record a million values to it UMA will still only send a count for each of the 50 buckets.

If you record a million events like 
ukm::builders::XYZ(source_id)
  .setX(x)
  .setY(y)
  .record(recorder);

UKM would conceptually want to send a million (source_id, x, y) tuples.  In practice, this would actually be truncated, and metrics that record too frequently are expected to sample to avoid hitting the truncation limit.  I think you are likely to run into problems with our bandwidth throttling before you hit performance costs from mojo calls.  Also, you'd still have to send all of the data process with the UkmService so that it can upload it.

Ah, I see. Yeah, I guess with sampling it's not an issue now considering we are only going to be reporting scroll latency cross-ipc. If we ever get to a point where we have a large number of different UKM sources reporting cross-process, this will increase in priority.