Re: [RFC/PATCH 1/5] gettext: fix bug in git-sh-i18n's eval_gettext() by using envsubst(1)
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 9, 2010, 10:52 UTC
- Message-ID
- <AANLkTins_qq=unv101JuV_CVvkp3KbTq5qycva7bZ7sm@mail.gmail.com>
- In-Reply-To
- <4CD9241F.6070807@viscovery.net>
On Tue, Nov 9, 2010 at 11:36, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 43 quoted lines
> Am 11/9/2010 10:49, schrieb Ævar Arnfjörð Bjarmason:
>> On Tue, Nov 9, 2010 at 10:47, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Am 11/9/2010 10:35, schrieb Ævar Arnfjörð Bjarmason:
>>>> Why is that a "*must*"?
>>> ...
>>>> But maybe you have reason to think otherwise? I haven't noticed any
>>>> noticable slowdowns from doing it this way, but maybe I've been
>>>> looking at the wrong thing.
>>>
>>> You didn't do your timings in Windows, did you? Every fork() that you can
>>> avoid is a win.
>>
>> What's the result of timing it on Windows?
>
> I do not have gettext, hence, I test 'git version' as a reference:
>
> $ time (for i in {1..100}; do git version; done) > /dev/null
>
> real 0m5.610s
> user 0m1.707s
> sys 0m0.712s
>
> Then I tested this function. It is not exactly the same that you tested,
> but it has the same number of subshells and builtin and external command
> invocations:
>
> eval_gettext ()
> {
> gettext "$1" |
> ( : `git-sh-i18n--envsubst <<< "$1"`
> git-sh-i18n--envsubst <<< "$1"
> )
> }
>
> $ time (for i in {1..100}; do eval_gettext foobar; done) > /dev/null
>
> real 0m20.578s
> user 0m8.457s
> sys 0m3.915s
>
> Note that there are only 100 iterations, so we are talking about 0.2
> seconds per eval_gettext call! That's an awful lot of time even for a
> single error message.Thanks for elaborating. But just so I understand you correctly it's a cost of invoking *any* program in shellscripts on Windows? So e.g. 10 sed calls would cost the same as 10 git-sh-i18n--envsubst calls (but of course 5 eval_gettext() calls, since it calls git-sh-i18n--envsubst twice).
So e.g. using eval_gettext once isn't a bigger problem than calling some trivial sed substitution twice?