New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 717808 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 731202



Sign in to add a comment

Avoid copying LatencyInfo

Project Member Reported by stanisc@chromium.org, May 3 2017

Issue description

When working on optimizing class layout ( issue 710933 ) I've noticed that the size of LatencyInfo is pretty massive at 640 bytes. It gets embedded in many other classes including all ui::Event derived classes and is passed by value a lot. I've estimated that LatencyInfo copy constructor is called ~1300 times per second(together in all processes) when just moving a mouse around.

The reason LatencyInfo is so big is that it has a built-in storage for 10 LatencyComponent items in the small map (vector based map).

Here is the class layout:

    class ui::LatencyInfo [sizeof = 640] {
      data +0x00 [sizeof=32] std::basic_string<char,std::char_traits<char>,std::allocator<char> > trace_name_
      data +0x20 [sizeof=568] base::SmallMap<...> latency_components_
      data +0x258 [sizeof=4] unsigned int input_coordinates_size_
      data +0x25c [sizeof=16] gfx::PointF input_coordinates_[2]
      <padding> (4 bytes)
      data +0x270 [sizeof=8] __int64 trace_id_
      data +0x278 [sizeof=1] bool coalesced_
      data +0x279 [sizeof=1] bool terminated_
      <padding> (2 bytes)
      data +0x27c [sizeof=4] ui::SourceEventType source_event_type_
    }

I've added some tracing to the copy constructor to see how long it takes to copy LatencyInfo. It isn't too bad - 0.003 ms on average, but in some cases I've seen up to 0.038 ms. But considering the large number of copies that might add up enough to affect responsiveness especially on devices with slower memory. 

Here are some optimizations to consider:
1) Reduce the size of LatencyComponent from 40 to 32 bytes. This could be possible if sequence_number was changed to int32_t and some fields were moved around to avoid padding. Is int64_t really necessary? Doesn't seem so.

The current layout is:
    struct ui::LatencyInfo::LatencyComponent [sizeof = 40] {
      data +0x00 [sizeof=8] __int64 sequence_number
      data +0x08 [sizeof=8] base::TimeTicks event_time
      data +0x10 [sizeof=4] unsigned int event_count
      <padding> (4 bytes)
      data +0x18 [sizeof=8] base::TimeTicks first_event_time
      data +0x20 [sizeof=8] base::TimeTicks last_event_time
    }


2) Reduce the default size of storage from 10 to 7. I did some debugging and it is very rare to see more than 7 items added to the storage.

3) Is is possible to pass LatencyInfo by ref and avoid the copying at all?
 
Components: UI>Input
Cc: tdres...@chromium.org vmi...@chromium.org
Components: -Speed>Telemetry Speed>Metrics
Cc: nduca@chromium.org
Owner: tdres...@chromium.org
Status: Assigned (was: Untriaged)
Yeah, this is definitely broken, and we've got some plans incubating on how to fix it. In the long run, we just want to pass around an identifier for the input event, and have a system for associating data with that identifier which doesn't require passing all this data around.

We should see a doc here in the next week or two. Let's park this on me for now, though it isn't clear who will drive this yet.
Cc: nzolghadr@chromium.org
Owner: sadrul@chromium.org
I think Sadrul's work here will cover this.
Sadrul, should this be duped with something you're tracking?

Comment 7 by maxlg@chromium.org, Jun 13 2018

ping.
sadrul@ any update on this?
Labels: Hotlist-DesktopUIToolingRequired Hotlist-DesktopUIChecked
*** UI Mass Triage***


Sign in to add a comment