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

On Thu, Feb 24, 2011 at 10:45, Erik Faye-Lund [off-list ref] wrote:

On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

quoted

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.

quoted

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).

quoted

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.