Avoid copying LatencyInfo |
||||||
Issue descriptionWhen 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?
,
May 3 2017
,
May 3 2017
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.
,
Aug 15 2017
,
Nov 23 2017
,
Feb 23 2018
I think Sadrul's work here will cover this. Sadrul, should this be duped with something you're tracking?
,
Jun 13 2018
ping.
,
Sep 25
sadrul@ any update on this?
,
Nov 20
*** UI Mass Triage*** |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by stanisc@chromium.org
, May 3 2017