Posted by: Anonymous Coward
on July 22, 2006 08:09 PM
The flames are unfortunate, but I'm replying here as the parent nicely summarizes a problem I too have noticed.
It's not just daemons and X that have the problem, and GNOME isn't alone, either. Try strace -efile . Due to the various places distributions put various files and testing for system and user configs, it's not uncommon at all for an app to check ten or more different locations for a single config file or resource (icon, cursor, font, etc) multiplied by sometimes fifty or more such files! (As a former power user of over a decade of a rather less Freedom oriented OS, it reminded me of the hundreds of lines of registry accesses I used to look at.) Fortunately, on a conventional desktop, many of these are common to many apps, and after the first access, the file or lack of file will be cached so it's just a cache check, but opening those first applications that actually read the data from disk into cache can be<nobr> <wbr></nobr>/quite/ the killer, timewise.
Thinking about it, it's not realistic to expect all distributions to settle on a common location for everything, but I wonder why the first such file opened couldn't be in a standardized location, say<nobr> <wbr></nobr>/etc/fslocations and ~/.fslocations or similar, and list the distribution/local reference location for all these things. One reference location to look (well, one each for system and user), which would list the single location for each category of file. As KDE or GNOME or whatever installed, it would update this file with additional local paths (entries appropriately namespace organized so as not to conflict with each other) as appropriate. Only if this file didn't exist, couldn't be read (wrong permissions), or didn't have the appropriate entry would apps fall back to checking their dozen different locations for each file.
That would add a couple more lookups per app, but would subtract hundreds in many cases, perhaps thousands in some.
Even if this weren't to become a full community standard, individual toolkits/DEs/whatever could have their own standard. In that case, it might add a few more lookups as the index file was looked for in all the various possible locations, but it would still be one file's lookups, while subtracting the same lookups for often scores of other files.
As for CUPS and etc, what about having a single discovery-lockfile, again, one at the system level and another at the admin-level user level, that toggled discovery on and off. To add a piece of hardware or just get the flexibility of being able to do so, with the performance tradeoff that goes with the flexibility of course, toggle it on. Toggle it off for streamlined use when such detection isn't needed.
Obviously it's not quite that simple, but the idea seems workable enough.
Learn about Linux
Download Linux
Get Linux help
Re:Scratch-centric design.
Posted by: Anonymous Coward on July 22, 2006 08:09 PMIt's not just daemons and X that have the problem, and GNOME isn't alone, either. Try strace -efile . Due to the various places distributions put various files and testing for system and user configs, it's not uncommon at all for an app to check ten or more different locations for a single config file or resource (icon, cursor, font, etc) multiplied by sometimes fifty or more such files! (As a former power user of over a decade of a rather less Freedom oriented OS, it reminded me of the hundreds of lines of registry accesses I used to look at.) Fortunately, on a conventional desktop, many of these are common to many apps, and after the first access, the file or lack of file will be cached so it's just a cache check, but opening those first applications that actually read the data from disk into cache can be<nobr> <wbr></nobr>/quite/ the killer, timewise.
Thinking about it, it's not realistic to expect all distributions to settle on a common location for everything, but I wonder why the first such file opened couldn't be in a standardized location, say<nobr> <wbr></nobr>/etc/fslocations and ~/.fslocations or similar, and list the distribution/local reference location for all these things. One reference location to look (well, one each for system and user), which would list the single location for each category of file. As KDE or GNOME or whatever installed, it would update this file with additional local paths (entries appropriately namespace organized so as not to conflict with each other) as appropriate. Only if this file didn't exist, couldn't be read (wrong permissions), or didn't have the appropriate entry would apps fall back to checking their dozen different locations for each file.
That would add a couple more lookups per app, but would subtract hundreds in many cases, perhaps thousands in some.
Even if this weren't to become a full community standard, individual toolkits/DEs/whatever could have their own standard. In that case, it might add a few more lookups as the index file was looked for in all the various possible locations, but it would still be one file's lookups, while subtracting the same lookups for often scores of other files.
As for CUPS and etc, what about having a single discovery-lockfile, again, one at the system level and another at the admin-level user level, that toggled discovery on and off. To add a piece of hardware or just get the flexibility of being able to do so, with the performance tradeoff that goes with the flexibility of course, toggle it on. Toggle it off for streamlined use when such detection isn't needed.
Obviously it's not quite that simple, but the idea seems workable enough.
Duncan
#