Hi,
I am the original reporter.
How time flies.
Back in 2008, when I measured the speed,
CPU was 1GHz class, one core, and the system had 512MB main memory.
(Under 32bit Debian/GNU Linux installed on real-hardware.)
In 2014: now my real CPU, Xeon, is 3GHz class (4 core, hyperthreading)
Debian GNU/Linux amd64 has 8GHZ main memory (in a VMplayer environment
with 4 CPU emulation).
So there is an issue of 64bit vs 32bit CPU and OS, but
anyway, I measured the speed again using a much larger
test input file of 63.5 MiB bytes (2014)
(vs 100 KiB (2008)) to obtain a meaningful number on today's fast CPU.
With 100KiB size bytes the speed was not measureable because CPU is now
so faster!
(the execution log is at the end.)
Then I noticed very INTERESTING DISCOVERY.
The low case now about 9 times slow down. (In comparison to x200-x400
slow down in 2008 it is more or less acceptable? It depends.)
What is interesting is this: NOTE THAT the slowdown characteristics is
TRANSPOSED in comparison to the data in 2008!
I had to re-read the execution log to make sure that I was not
hallucinating.
How interesting.
2014 table
value of
LANG
|
V | ja_JP.ujis | C |<=== value of LC_ALL
----------+-------------+-------------------
ja_JP.ujis| 1.833s | 1.845s
----------+-------------+------------------
C | 0.219s | 0.226s
----------+-------------+-------------------
While the slow execution time of 2008 is in the left COLUMN
it is the first ROW in 2014. Strange, isn't it?
I have to agree that the bug is too old now and that
the transposition of the table that shows slowdown pattern
probably means that there is a different bug
hmm, it is more likely
the UTF-8 slowdown mentioned in one of the Savanna bugs mentioned in
the bug discussion before
(http://savannah.gnu.org/bugs/index.php?29391
-i and utf8 slowness, speedup idea
)
ja_JP.ujis is basically UTF-8. So a known different bug now, I think)
So I concur this bug should be closed.
I am afraid that the fast CPU speed masks all these minor deficiencies
of programs under the rug. Reminds me of MS policy of throwing faster
CPU and more memory at slow and bloated OS.
It is the curse of very fast CPU and ever advancing hardware.
Well, maybe that is life.
TIA
cf.
2008 data quoted here.
value of
LANG
|
V | ja_JP.ujis | C |<=== value of LC_ALL
----------+-------------+-------------------
ja_JP.ujis| 8.084s | 0.022s
----------+-------------+------------------
C | 8.488s | 0.010s
----------+-------------+-------------------
June 2014 execution log:
+ SRC=/FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ wc /FF-NEW/log443-mozmill-memcheck-fixstack.txt
608621 3316476 63137313 /FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ LC_ALL=C
+ LANG=C
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt
real 0m0.219s
user 0m0.204s
sys 0m0.012s
+ strace -o /tmp/t-C-locale.out egrep -i backslash
/FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ LC_ALL=ja_JP.ujis
+ LANG=ja_JP.ujis
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt
real 0m1.784s
user 0m1.768s
sys 0m0.004s
+ strace -o /tmp/t-ja-locale.out egrep -i backslash
/FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ LC_ALL=ja_JP.ujis
+ LANG=C
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt
real 0m0.223s
user 0m0.216s
sys 0m0.004s
+ strace -o /tmp/t-mixed-locale-1.out egrep -i backslash
/FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ LC_ALL=C
+ LANG=ja_JP.ujis
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt
real 0m1.799s
user 0m1.784s
sys 0m0.012s
+ strace -o /tmp/t-mixed-locale-1.out egrep -i backslash
/FF-NEW/log443-mozmill-memcheck-fixstack.txt
ishikawa@vm-debian-amd64:/home/ishikawa/repos/kinput2-wnn-v3.1-ci-mods$
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
