| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A) When a QEdidParser gets built, the code populates a QMap by parsing
the system's pnp ids file. With > 2000 entries in the file, that's 2000+
allocations for the QMap, plus 4000+ allocations for key/value
(QStrings), plus a bunch of temporaries created for processing.
What's more, on XCB and EGLFS, a QEdidParser gets built *per screen*;
the map is not shared and gets rebuilt for each screen.
It's however completely unnecessary to keep this map in memory. The
lookup is required only once per monitor change event, which, apart from
application startup, is an extremely rare event.
When such an event happens, and we have to lookup a vendor id, we can
just process the pnp database "on the fly", therefore removing the
constant memory usage from the application run.
In order to also avoid an allocation spike, just don't build a map at
all: simply process the file, using no memory allocations, one line at a
time while searching for the vendor id. I was unable to find
information about the file format, so I am not sure if it's guaranteed
that it's kept sorted by id (this could allow for a faster fail path).
B) In case of a cache miss, a hardcoded vendor table is used to try and
identify the manufacturer.
Look up in the hardcoded table using binary search, rather than a linear
scan, and don't allocate memory for each element processed in the list
(!). The size of the list (2000+) is big enough to completely justify
binary search.
C) Drive-by, remove a TOCTOU bug when opening the system file.
D) Drive-by, fix the includes in the header to IWYU.
Change-Id: I57c7cbd09a145c6efe3023c227ed36b24bed96f9
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
