Hi, > Before asking here I went thru several mailing list archives. What I > found was a general argument along the lines of "don't add _that_ hwcap > because that will increase the size of the list of paths that you have > to stat(2) in order to find the library and that's slow". In > particular upstream doesn't seem to like the idea much. I just can't > find the reason why they think the stat(2) call is _so_ expensive that > it will hurt system performance. There was some mention of a glib > issue with plugins. I couldn't find further data points on that...
The main problem with adding hwcap is that the number of directory to be traversed doubles with every addition, which is an exponential thing; rather than something linear. Looking at the rate of hardware changes, we will ideally be wanting to add a new hwcap entry just about every year; which results roughly in x10 time penalty every 3 years. > What that means is that you need to make about 2000 stat(2) calls to > get _anywhere_ near what's measurable by a human and about 20000 to > start getting said human annoyed. Which will be reachable within 10 or 20 years of time. Thus, to be realistic, a linear or O(1) scheme, or some kind of library path caching scheme is required; time to do some coding? Ref: Having a hwcap of 'a' and 'b' and 'c' requires lookup of a/ a/b/ a/b/c a/c/ b/ b/c c/ Having a hwcap of 'a' and 'b' and 'c' and 'd' requires lookup of a/ a/b/ a/b/c a/c/ b/ b/c c/ a/d a/b/d a/b/c/d a/c/d b/d b/c/d c/d d regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]