performance of pci_device_get_{vendor, device}_name() in X server startup

[Richard Barnette]

On Jun 8, 2010, at 2:51 PM, Mike Travis wrote:

>
>
> Mikhail Gusarov wrote:
>> Twas brillig at 14:26:32 08.06.2010 UTC-07 when jrbarnette at chromium.org
>> did gyre and gimble:
>> RB> I'd like advice/opinions on which of these might be the most  
>> eagerly
>> RB> embraced (or at any rate, least vigorously opposed :-) ), or  
>> whether
>> RB> there's a better idea I've overlooked.
>> The Right Thing that immediately comes to mind is fixing libpciaccess
>> internals to be able to read data from saner (indexed,
>> string-compressed, with common strings merged for different PCI ids)
>> file format to avoid problem with linear search altogether. Given
>> simplicity of data format it should be nearly trivial task.
>
> Another thought would be to cache the strings related to the devices
> attached to the system and save them some place.  Only need to go to
> big database if new device is attached.


Yup, I've thought about variations on this theme.  It works well enough
for Chrome OS, where the cache file could be generated once when the
system software was installed (i.e. at manufacturing time), but as a
general purpose solution usable to any Linux distro, maintaining the
cache as up-to-date if a user upgraded system hardware would be a bit
more work.

Assuming we declare that generating and maintaing the cache file is
SEP, there are two ways to go about it:
   * Enhance libpciaccess to search a longer list of files, so that
     the cache file could be checked ahead of the full index.   
Currently,
     libpciaccess looks for "pci.ids.gz" and then "pci.ids" in a  
directory
     that's selected at configure time.  The change would be to have two
     configured directories, and search for four files.
   * Just add the option to X to specify the "pci.ids" file on the
     command line, and pass the cache file (or the full index) to
     the X server.

-- jrb