This is the mail archive of the
mailing list for the glibc project.
Re: prelinking speed
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Fri, 4 Oct 2002 15:49:16 +0200
- Subject: Re: prelinking speed
- References: <200210041329.JAA20215@bromo.msbb.uc.edu>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Oct 04, 2002 at 09:29:34AM -0400, Jack Howarth wrote:
> Now that glibc and prelink are out, I was wondering what the
> exact situation was with potential improvements in the speed
> at which prelink processes the files on a system. Are there some
> potential areas that are choke points at the moment that could
> greatly increase the speed at which prelink can prelink a large
> filesystem? Thanks in advance for any info.
Well, prelink could be obviously speeded up by threading it and running
about 2 as many threads as there are CPUs.
But that's not the usage for which it was designed.
The intended use is to run it from cron (say weekly and more often
if some important binaries or libraries are known to be changed since last
prelink), ie. as a batch job. And batch jobs better not eat all CPUs
so that there is enough CPU power for other more important tasks.