[PATCH] pci.id performance patch

[Ihno Krumreich]

On Thu, Oct 12, 2006 at 11:18:40AM -0400, David Zeuthen wrote:
> On Thu, 2006-10-12 at 16:43 +0200, Danny Kukawka wrote:
> > On Wednesday 11 October 2006 06:17, David Zeuthen wrote:
> > > New commits:
> > > diff-tree 5e33459557cf9d4680f894392a834b7752acd60a (from
> > > e6b0bd21ae250d6d589e2584fd624b7bd2fa6835) Author: David Zeuthen
> > > <davidz at redhat.com>
> > > Date:   Wed Oct 11 00:17:34 2006 -0400
> > >
> > >     use mmap to access pci.ids and usb.ids
> > >
> > >     Goodbye 580KB of writable memory! :-)
> > 
> > I would propose to undo the change for pci.ids. We think the change from 
> > writable memory to readonly memory doesn't bring better performance of HAL. 
> > If we use writable memory we can optimize the process of search in the file.
> 
> This doesn't makes sense to me at all. Have you done any profiling to
> actually verify that searching in pci.ids is a problem? If so, can you
> share that? 
> 

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 %).

> 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. 

> 
> Anyway, if you still think we need to speed it up the approach would be
> this
> 
>  1. If cache file exist, compare mtime of cache file and pci.ids
>  2. if pci.ids is older goto 5.
>  3. Create binary optimized search structures from pci.ids
>  4. Save those to a cache file file
>  5. mmap the cache file
>  6. setup inotify-ish stuff to track file changes and goto 1. on changes
>  7. profit
> 
> That's what I'm planning to do for .fdi files anyway. Right now the fdi
> rules files are "only" 80kb in memory (compared to 164k on disk) but
> that is expected to grow a lot when we get battery recall data and
> suspend quirks into HAL. Using mmap for that will be significant at
> least long term.

This is the full blown solution. But I think it is not worth the effort.
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.

Best regards/Mit freundlichen Grüßen

Ihno

"Never trust a computer you can lift."
--
Ihno Krumreich            ihno at suse.de
SUSE LINUX Products GmbH  Projectmanager S390 & zSeries
Maxfeldstr. 5             +49-911-74053-439
D-90409 Nürnberg          http://www.suse.de