[PATCH] pci.id performance patch

[David Zeuthen]

On Mon, 2006-10-16 at 13:31 +0200, Ihno Krumreich wrote:
> I have done profiling and the function to read the next line in the pci.id file
> used a significant part of the CPU-time on startup (40 to 50 %).

Can you elaborate a bit? What setup? How many PCI devices? Do you have
output from profilers?

For example, examining this profile (just load it into sysprof, sysprof
is available from GNOME CVS under cvs module 'sysprof')

 http://people.freedesktop.org/~david/hal-profile/2/hal-profile2

that I made available last week, you can see

 http://people.freedesktop.org/~david/hal-profile/2/profile-ids.png

that ids_pci_find accounts for 3.77% of all execution time. Since total
execution time was around 0.9 seconds, this is ~ 30ms. So if you have a
patch that cuts this in half it will save us 15ms. So we would be
trading off 15ms for 580kb. Not a very good deal. 

(btw, sysprof totally rocks, it's extremely easy to use and gives me the
data I need without having to learn a bunch of command line options etc.
Søren rocks!)

Anyway, it may look different on other setups though. I'd like to see
profiles (ideally sysprof profiles) from interesting systems ranging
from N770, OLPC, normal laptops over to big iron servers with thousands
of disks. HAL should be able to run nice on all of them I think. If we
don't already we need to fix that.

I'm not sure where you get the 40 to 50% from... it should be much lower
than 3% since we used to do a lot of useless work in hal. Perhaps you
can give details about the setup?

> > Saving 580kb of memory is _significant_. Making search within a function
> > 50% faster doesn't really tell me anything, need profiles a'la the
> > sysprof stuff I was posting the other day.
> 
> The overall memory foodprint of hal does not change. 

Well, the patch I committed makes us indeed save 580kb which is pretty
significant. With what I understand your patch your doing that would
still keep the pci.ids data in writable memory.

> I detected the problem with the pci.id file by accident. I was searching for
> other performance issues, when a lot of devices are attached (1000 Disks for example).
> I already had the code for solving the pci.id problem. I just needed 5 minutes to adopt
> it. As this problem has not really slowed down hal, I doubt whether the full blown
> solution makes sense. It just produces more dead code that is lieing around.

Yea, I'm not sure it's worth it. Just curious, how many PCI devices do
you have even in systems with thousands of disks? I think it's still
somewhat bounded, e.g. the disks are many separate LUN's hanging off a
few SCSI controllers that indeed are PCI devices, yes?

     David