[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One year since last libtool release

From: Bob Friesenhahn
Subject: Re: One year since last libtool release
Date: Wed, 4 Nov 2009 12:45:56 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]