Roland Mainz wrote:
> Bob Friesenhahn wrote:
>   
>> Dolt illustrates that libtool performance should improve. However, the
>> performance numbers posted by Dolt's author are based on an outdated
>> version of libtool 1.5.X and libtool 2.2.X (containing four more years
>> of development) is considerably faster.
>>
>> I have already suggested on the libtool mailing list that DTrace can
>> be used to help evaluate where libtool is losing time.  This is an
>> area where OpenSolaris developers can help the open source community
>> at large and illustrate that OpenSolaris is able to offer something
>> that Linux does not.
>>     
>
> Per alanc's request I already did some investigation in this area since
> the FOX tree has some compile time trouble with libtool...
> ... part of the problem is that "libtool" acts like half a |fork()|-bomb
> and triggers many many child processes (as seen with the Dtrace
> fork-o-meter.d script).
> I did a small test and replaced #!/usr/bin/bash with #!/usr/bin/ksh93
> and did some other changes - the resulting build  time spend with
> libtool processes (e.g. "bash") droped to ~~46% of the original
> execution time (measured over five builds each (OkOk... that's not a
> perfect benchmark... ;-/ (nor do I claim to be an expert in
> benchmarking... ;-/))) ... and I'm confident that more performance can
> be pressed out of te script by using more of the ksh93 builtin commands
> (e.g. "basename" etc.) and replace some calls to "sed" by builtin string
> operators... and finally the ksh93-integration update1 will deliver
> "shcomp" (the ksh93 shell script compiler) which will help to squish
> even more performance out of such a script...
>   

   One other optimization that I was considering was to use 
pre-generated config.cache
   files. For eg. in the drivers subdirectory the config.cache generated 
for the first driver
   built is copied to a common location and then that is passed as a 
parameter while
   calling configure for the rest of the drivers. This avoids a whole 
plethora of redundant
   checks the results of which are already in the cache.

Regards,
Moinak.

> ----
>
> Bye,
> Roland
>
>   


Reply via email to