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.
next prev parent 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.