On Fri, Apr 20 2018, Martin Ågren wrote:
> On 20 April 2018 at 11:59, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote:
>>
>> On Fri, Apr 20 2018, Johannes Schindelin wrote:
>>
>>> The runtime of a simple `git.exe version` call on Windows is currently
>>> dominated by the gettext setup, adding a whopping ~150ms to the ~210ms
>>> total.
>>>
>>> Given that this cost is added to each and every git.exe invocation goes
>>> through common-main's invocation of git_setup_gettext(), and given that
>>> scripts have to call git.exe dozens, if not hundreds, of times, this is
>>> a substantial performance penalty.
>>>
>>> This is particularly pointless when considering that Git for Windows
>>> ships without localization (to keep the installer's size to a bearable
>>> ~34MB): all that time setting up gettext is for naught.
>>>
>>> So let's be smart about it and skip setting up gettext if the locale
>>> directory is not even present.
>
>> If you don't ship git for windows with gettext or a podir, then compile
>> with NO_GETTEXT, then we won't even compile this function you're
>> patching here. See line 30 and beyond of gettext.h.
>>
>> Are you instead compiling git for windows with gettext support with an
>> optional add-on package for i18n, so then this podir conditional would
>> pass?
>>
>> In any case, if this is actually the desired behavior I think it's worth
>> clearly explaining the interaction with NO_GETTEXT in the commit
>> message, and if you *actually* don't want NO_GETTEXT I think it's useful
>> to guard this with something like MAYBE_GETTEXT on top, so this code
>> doesn't unintentionally hide installation errors on other
>> platforms. I.e. something like:
>>
>> int have_podir = is_directory(podir);
>> if (!have_podir)
>> #ifdef MAYBE_GETTEXT
>> return;
>> #else
>> BUG("Broken installation, can't find '%s'!", podir);
>> #endif
>
> Is it fair to say that such a broken installation would function more or
> less well before and after Dscho's patch, and that your approach would
> render such an installation quite useless?
Yes my thown out there for the purposes of discussion suggestion may
break things for Dscho, or not. I'm just saying that we should document
*what* the use-case is.
Because it's not just important to massage the code so it works now, but
to document what the use-case is, so someone down the line who things
"oh why are we doing that" has a clear answer.
> Do we have some other similar
> cases where we go BUG("I could not find a resource. I could manage
> fairly well without it, but you seemed to want it when you installed
> me.")? I wonder what other well-respected software do if they can't find
> their translations.
E.g. my recent 1aca69c019 ("perl Git::LoadCPAN: emit better errors under
NO_PERL_CPAN_FALLBACKS", 2018-03-03) does similar things, we *could*
carry on in certain cases instead of dying there (or not, depending on
the codepath).
But in general, I don't think there's any reasonable use-cases for git
needing to repair from a broken or semi-broken installation that aren't
so specific that they can be explicitly declared, e.g. in this
hypothetical MAYBE_GETTEXT case.
Otherwise if it's not conditional, e.g. my git on Debian that won't ever
need this is going to just subtly regress because the FS is broken or
whatever, and I don't think we should have such code in git running
unconditionally.
> I suppose the logic could be the other way round, i.e., with a flag
> REALLY_REQUIRE_GETTEXT_AT_RUNTIME. But I also wonder if a user who does
> not notice that the installation is broken without us screaming BUG in
> their face, really minds the "brokenness" that much.
Without the BUG(...) that user is going to spend time fiddling with his
i18n settings before finally realizing that his package is broken, much
better to just emit an error so it's obvious that things are broken,
rather than taking the fallback path.
