Re: hwcap supporting architectures?
> 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?
Having a hwcap of 'a' and 'b' and 'c' requires lookup of
Having a hwcap of 'a' and 'b' and 'c' and 'd' requires lookup of