On Wed, 4 Nov 2009, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 06:25:26PM CET:
We should fix the libltdl performance problem (attempting to dlopen
a .a file due to the preloader) before making a release. This is
something I am pretty interested in (it causes a HUGE performance
hit) so I will be looking into a fix eventually if no one else gets
to it first.
Will you please write a testcase for this issue first thing you do? If
Autotest is too complicated, then just any kind of small reproducible
example, but we *need* a test case, and you are in the best position to
write it.
I am not sure how one would test for this in an automated fashion
since the only effect is a performance reduction. It requires
system-dependent tools in order to watch the system calls and see what
is actually going on.
From what I have observed, the minimal run-time for a program which
loads and unloads two modules differs by a factor of 5-6X between
loading via the .so files, or loading via the .la files. This means
that the actual timing difference must be far larger. These slow-down
factors are observed under Solaris and FreeBSD, but are likely less
under Linux since Linux glibc seems to cache and filter dlopen
requests. I am not sure what fraction of the time is wasted due to
passing dlopen requests for .a archive files to dlopen, but it is
surely large since this is done for all the dependency libraries (e.g.
libc) as well.
Besides performance, there may be minor security implications since an
illicit .a can be inserted anywhere the system searches for libraries,
including in LD_LIBRARY_PATH.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
