[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.
From: |
Gary V. Vaughan |
Subject: |
Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time. |
Date: |
Mon, 28 Nov 2011 21:18:37 +0700 |
Hi Peter,
On 28 Nov 2011, at 18:05, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-11-28 10:20:
>> On 28 Nov 2011, at 15:48, Peter Rosin wrote:
>>> Gary V. Vaughan skrev 2011-11-25 09:57:
>>>> Determine, on a function by function basis, what XSI features
>>>> are available in the shell that is actually running the script,
>>>> rather than the one that was picked at configure time by the
>>>> re-execution engine.
>>>
>>> Doesn't this mean that the libtool script will do a number of
>>> extra forks each time it is run?
>>
>> Well, yes and no. There will be an extra 4 or 8 evals (depending
>> on whether the XSI function is chosen) as libtool starts up when
>
> That's the evals in sub-shells, right? Those with this pattern:
>
> if $_use_fast_funcs && (eval ...) 2>/dev/null
> then
> eval '...
>
> or this:
>
> if (eval ...) 2>/dev/null
> then
> eval '...
Yes, that's them.
>> [[snip]]
>>> If that's the case, I would like
>>> to know how that impacts the execution time on Cygwin/MinGW...
>>
>> I don't have access to Windows so I can't actually measure it, but
>> I doubt that the difference will be noticeable for even a large
>> project, and quite possibly a small project like libltdl that only
>> runs libtool a hand full of times will actually be (imperceptibly)
>> faster.
>
> I think you are underestimating the Cygwin fork pain.
>
> BTW, libltdl runs libtool more like 20 times, but I agree it's very
> small and the number of forks will not matter much.
>
> My typical use case is "mid-sized" at a magnitude or so larger, and
> even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
> be too harsh with a couple of extra forks - a minutes or so on the
> wall clock time. But it would really add to the pain on some
> (hypothetical?) large project with thousands of libtool invocations.
> That's all I'm saying, but *I* am not building any of those...
Maybe I should switch the sense of the _use_fast_funcs, so that the
pattern becomes:
if $libtool_force_fast_funcs || (eval ...) 2>/dev/null
then
eval '...
And then recommend that cygwin users always use an XSI and += capable
shell, with libtool_force_fast_funcs=: in the environment to cut out the
forks?
> Hmm, looking closer, shouldn't _use_fast_funcs have some kind of lt
> prefix?
Good point. I'll add a prefix before pushing. Thanks.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
- [PATCH 1/4] libtoolize: rename and reorder copy filter functions., Gary V. Vaughan, 2011/11/25
- [PATCH 2/4] maint: share useful functions from general.m4sh., Gary V. Vaughan, 2011/11/25
- [PATCH 4/4] libtoolize: refactor copying filter creation., Gary V. Vaughan, 2011/11/25
- [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time., Gary V. Vaughan, 2011/11/25
- Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time., Peter Rosin, 2011/11/28
- Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time., Gary V. Vaughan, 2011/11/28
- Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time., Peter Rosin, 2011/11/28
- Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.,
Gary V. Vaughan <=
- Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time., Bob Friesenhahn, 2011/11/28