Re: What's cooking in git.git (Feb 2011, #05; Wed, 23)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 24, 2011, 17:47 UTC
Message-ID: <AANLkTike1qDGJ-mLsSRYpBk59_evk9x5oFeGt5RSUg3d@mail.gmail.com>
In-Reply-To: <AANLkTimWy+W+rcZHsac_n--y9iMeaoO66CPZVbN1VBp2@mail.gmail.com>

On Thu, Feb 24, 2011 at 10:45, Erik Faye-Lund <kusmabite@gmail.com> wrote:

Show 17 quoted lines

> On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> And then there's the issue that unlike the C patches these will not be
>> a no-op that'll be optimized away by the compiler. We'll be calling an
>> external program for displaying messages. While this is a trivial cost
>> on Unix (especially in the context we're using it, i.e. not in tight
>> loops) it's more expensive on Windows.
>>
>
> Ouch. I remember this being brought up earlier, but I just assumed it
> had been fixed somehow. The shell-scripts are already pretty slow on
> Windows, and the overhead of starting a new process here is quite
> significant.
>
> It sounds to me like we should revert these patches in msysGit, at
> least until there's some actual translations in place (and that time
> actually goes into something useful)...

IIRC last time this was discussed I asked whether the size of the binary mattered for execution startup time (i.e. more so than on Unix). We're only invoking printf(1) and git-sh-i18n--envsubst, both of which only are (or only need to be) linked to libc.

It would also be interesting to have some real world benchmarks on Windows with and without this series, maybe it won't be so bad.

I think in the long term we probably want to rewrite the remaining *.sh programs in C anyway.

Show 31 quoted lines

>> I don't see any way to deal with that short of implementing some
>> pre-processor, but I think the cost is worth it, but others might
>> disagree of course.
>>
>
> I'm not so sure. This is mostly a problem with the no-op version on
> Windows (due to the slow process-startup there), but I think Git for
> Windows probably wants to have i18n support in it's distribution as it
> strives to be the canonical Git-distribution for Windows. But if we
> do, there's nothing to optimize. There's no no-op-stuff, and we need
> to spend that time getting translations.
>
> It might be that some people that build Git for Windows themselves and
> know that they don't want a translated Git could benefit from a
> pre-processor, but I'm not so sure. Translated strings occur when
> there's communication going on between Git and the user, and then
> we're some times waiting for user-input, and even when we aren't it
> should be relatively few messages (unless verbose flags are turned on,
> which isn't an important use-case performance-wise to me).
>
>> Anyway, I can submit these patches (around 53) real soon, or wait
>> until the current series settles. It's the same to me, which would you
>> prefer?
>>
>
> If we're going to revert these patches in 4msysgit.git, then I can
> imagine that the process becomes very awkward and error-prone if we're
> going to diverge for a long time. So I think it'd make more sense for
> us (the msysgit-developers, that is) if it was merged together with
> the first translations. But that might be sub-optimal for the rest of
> you guys.

If it comes to that it'll be easier to have some perl script that converts C<"$(eval_gettext "foobar: \$whatever")"> back to C<"foobar: $whataver"> at build time than revert the patches.