All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC/PATCH 1/5] gettext: fix bug in git-sh-i18n's eval_gettext() by using envsubst(1)
Date: Tue, 9 Nov 2010 10:35:26 +0100	[thread overview]
Message-ID: <AANLkTinKYJtaDjwEk0OqebBnL6+wvVO4wfWg7G-VYh7d@mail.gmail.com> (raw)
In-Reply-To: <4CD8F965.6050402@viscovery.net>

On Tue, Nov 9, 2010 at 08:33, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/8/2010 23:39, schrieb Ævar Arnfjörð Bjarmason:
>>     eval_gettext () {
>>       gettext "$1" | (export PATH `envsubst --variables "$1"`; envsubst "$1")
>>     }
>
> So, for every message printed, you have at least 3 fork()s (usually even
> more)! I'm not happy about that. You *must* avoid this at least for
> NO_GETTEXT builds, but if you can reduce them even for no-NO_GETTEXT
> builds, it would be great.

Why is that a "*must*"? For the GNU gettext versions (our will be
faster, if anything):

    $ time (for i in {1..1000}; do gettext "foobar"; done) >/dev/null
    real    0m3.219s
    user    0m0.253s
    sys     0m2.570s

    $ time (for i in {1..1000}; do eval_gettext "foobar"; done) >/dev/null
    real    0m12.615s
    user    0m1.264s
    sys     0m12.384s

So that's around 0.003 seconds and 0.01 seconds per message for
gettext() and eval_gettext() respectively.

I'm not indifferent to that slight cost, but (almost?) all of the
eval_gettext messages we have are just printing out an error message
before we die. None of them are inside a tight loop. This is the
typical use case:

    git-am.sh:    eval_gettext "When you have resolved this problem
run \"\$cmdline --resolved\".
    git-am.sh:                      clean_abort "$(eval_gettext "Patch
format \$patch_format is not supported.")"
    git-am.sh:      die "$(eval_gettext "previous rebase directory
\$dotest still exists but mbox given.")"
    git-am.sh:              die "$(eval_gettext "Dirty index: cannot
apply patches (dirty: \$files)")"
    git-am.sh:                      eval_gettext "Patch is empty.  Was
it split wrong?
    git-am.sh:      say "$(eval_gettext "Applying: \$FIRSTLINE")"
    git-am.sh:              eval_gettext 'Patch failed at $msgnum
$FIRSTLINE'; echo
    git-bisect.sh:                  die "$(eval_gettext "'\$arg' does
not appear to be a valid revision")"
    git-bisect.sh:          *)              die "$(eval_gettext "Bad
bisect_write argument: \$state")" ;;
    git-bisect.sh:                revs=$(git rev-list "$arg") || die
"$(eval_gettext "Bad rev input: \$arg")" ;;
    git-bisect.sh:                          die "$(eval_gettext "Bad
rev input: \$rev")"
    git-bisect.sh:         die "$(eval_gettext "'\$invalid' is not a
valid commit")"
    git-bisect.sh:  test -r "$file" || die "$(eval_gettext "cannot
read \$file for replaying")"
    git-bisect.sh:      eval_gettext "running \$command"; echo
    git-bisect.sh:    echo >&2 "$(eval_gettext "bisect run failed:
    git-bisect.sh:    echo >&2 "$(eval_gettext "bisect run failed:

The cost for that is going to be much less than the time we spend on
forking out to sed, grep and other similar utilities inside our shell
scripts. If eval_gettext() is slowing things down noticeably that's
probably a sign that we need to rewrite the script in C, not
micro-optimize the eval_gettext() implementation.

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.

  reply	other threads:[~2010-11-09  9:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22  7:18 Buglet in i18n? Johannes Sixt
2010-10-22  8:20 ` Ævar Arnfjörð Bjarmason
2010-10-22  8:34   ` Jonathan Nieder
2010-10-23 11:32     ` Ævar Arnfjörð Bjarmason
     [not found]       ` <20101023182940.GD21040@burratino>
2010-10-30  9:14         ` Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 0/5] ab/i18n: Things I'll add in the next iteration Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 1/5] gettext: fix bug in git-sh-i18n's eval_gettext() by using envsubst(1) Ævar Arnfjörð Bjarmason
2010-11-02  8:33             ` Johannes Sixt
2010-11-08 22:39               ` Ævar Arnfjörð Bjarmason
2010-11-09  7:33                 ` Johannes Sixt
2010-11-09  9:35                   ` Ævar Arnfjörð Bjarmason [this message]
2010-11-09  9:47                     ` Johannes Sixt
2010-11-09  9:49                       ` Ævar Arnfjörð Bjarmason
2010-11-09 10:36                         ` Johannes Sixt
2010-11-09 10:38                           ` Erik Faye-Lund
2010-11-09 10:52                           ` Ævar Arnfjörð Bjarmason
2010-11-09 11:42                             ` Johannes Sixt
2010-11-09 11:57                               ` Ævar Arnfjörð Bjarmason
2010-11-09 12:22                                 ` Johannes Sixt
2010-11-09 12:38                                   ` Ævar Arnfjörð Bjarmason
2010-11-09 12:53                                     ` Johannes Sixt
2010-11-09 13:02                                       ` Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 2/5] gettextize: git-clone: !fixup "basic messages" Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 3/5] gettextize: git-init: " Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 4/5] gettextize: git-revert: !fixup "Your local changes" Ævar Arnfjörð Bjarmason
2010-10-31 11:34           ` [RFC/PATCH 5/5] gettextize: git-merge: !fixup "basic messages" Ævar Arnfjörð Bjarmason
2010-10-22  8:49   ` Buglet in i18n? Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinKYJtaDjwEk0OqebBnL6+wvVO4wfWg7G-VYh7d@mail.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.