libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take


From: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Date: Fri, 27 Aug 2010 18:09:13 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 8/27/2010 5:48 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 27, 2010 at 10:23:31PM CEST:
>> Original:
>> real    25m3.886s
>> user    6m24.620s
>> sys     11m13.787s
>>
>> With the functions moved ahead of func_mode_compile:
>> real    24m34.235s
>> user    6m30.590s
>> sys     11m23.878s
>>
> Yes, but there is a significant speedup in real time!?  That makes
> little sense, unless the system was busy doing other things also,
> for the first run.

Well, yeah -- it's windows. Who KNOWS what it is doing behind the
scenes.  Also, I was taking the time to compose all those other emails
on the same machine; I've got two cores and was only running make -j1,
but I'm not surprised there was some impact on the 'real' numbers.

But that should not have affected the user and sys numbers.

> 5% sucks a bit, fixing that should be a TODO item.

It's closer to 3%:

user: 6:24 = 384; 6 seconds = 1.5%
sys:  11:13 = 673; 10 seconds = 1.5%

Not great, and it would be nice to fix -- but not terrible.  Also, I
expect the impact on REAL operating systems would be less; I seem to
recall that along with fork() performance, cygwin is really bad (slow)
at parsing shell scripts.

If we can do the magic m4 func_to_host guts-replacement, instead of
using the indirection variables, that should help.  But that is a longer
term project.

--
Chuck




reply via email to

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