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

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

 



On Thu, Feb 24, 2011 at 1:32 AM, Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> 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)...

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]