Re: Intend to create an -fPIC library package...
> Whether we should recommend using static libraries is another matter
> entirely; indeed performance does go down a teeny weeny bit when using
> shared libraries, but the difference shouldn't be *that* large; if it
> is, that probably means they're using a twisty maze of function calls,
> all alike, that they probably shouldn't be doing.
As I understand it, the performance drawbacks of a shared library are:
1) The PIC code and its use of a GOT. Given that we're talking about a
PIC static library, this is not relevant.
2) Runtime linking. This is overhead at application startup time.
Something that embeds an SQL engine should not, I think, start up too
frequently. Am I wrong?
So what is the real performance advantage of this -fPIC static library?
To me it looks like a different, less desirable, way to implement the
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/