On Fri, Mar 20, 2009 at 08:57:20AM +0100, Pierre Bourgin wrote: > > Right now, the main problem is that adding HDAUDIO support from INF > files costs a lot: about 50 seconds of INF files parsing instead of > 20/30 seconds for PCI devices search only (for 2GB of drivers - 1800 > .inf files to check) ... > I have to figure out how to write more efficient perl code ;-) but in > the other hand, have to parse a lot of INF files line by line, so a lot > of I/O.
I think searching for are reading all of those INF files is what takes almost all of the time. > I'm also thinking about a cache of INF files (generated by the system > that hosts the unattended files and windows drivers) to speed up search > on the unattended-client side. There is more than one solution that would work. One solution I can think of is to sort all of the driver file directories into a new hierarchy that gives you the information that you need at install time. For example, if all the drivers were sorted in a tree such as /bus/vendor/device/... that would cut down the amount of work that you have to do at scan time. (I'm assuming that you only need those three items to identify the driver properly). By splitting the INF parsing to a separate program, the scanning part should be really fast. For example, the parsing program would sort all of the driver directories like: win_drivers/PCI/8086/24C5/1/... win_drivers/PCI/8086/24C5/2/... win_drivers/PCI/8086/C592/1/... win_drivers/USB/12536/382/1/... win_drivers/HDAUDIO/3882/39392/1/.. You should probably allow multiple drivers under the same vendor/device and let Windows sort it out at install time. Having a few extra drivers probably doesn't hurt. Then the scan program just adds all of the driver directories under the appropriate bus/vendor/device if they exist and doesn't have to read ANY INF files at all. This probably uses more disk space since you would probably treat win_drivers as a temporary directory that would be rebuilt every time that you updated your driver set. A second solution would be to use an index file rather than copying the driver files around. This is probably nicer. For this case, the index file could be a flat file with basically two fields. The first being the bus/vendor/device string used as a key and the second field is the path to the driver files. The scan program would then load this index into a hash. If the key exists in the hash, then we have the driver and the path. The drawback with this one is that it probably uses more memory since we load the entire index. (However, we probably would need more than 10000 drivers before we used more than 500k.) My gut feeling is that the second solution is probably faster for the scan since there are fewer network filesystem reads. Yes, there is probably more data read, but it is all read in one shot rather than directory reads for every device in the system. Either of these two solutions would likely bring the scan time to less than a couple of seconds. Now that I have it all written out, I like the second solution better. It also wouldn't be much of a change to your code. Allan. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ unattended-devel mailing list unattended-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unattended-devel
