multibyte performance
I did some benchmarking with/without multibyte support using current.
(1) regression test
With multibyte support:
9.52user 3.38system 0:59.27elapsed 21%CPU (0avgtext+0avgdata 0maxresident)k
Without multibyte support:
8.97user 4.84system 1:00.85elapsed 22%CPU (0avgtext+0avgdata 0maxresident)k
(2) pgbench
With multibyte support(first column is the concurrent user, second is
the TPS):
1 46.004932
2 70.848123
4 88.147471
8 90.472970
16 96.620166
32 95.947363
64 92.718780
128 61.725883
Witout multibyte support:
1 52.668169
2 68.132654
4 79.956663
8 81.133516
16 96.618124
32 92.283645
64 86.936559
128 87.584099
for your convenience, a graph is attached(bench.png).
(3) testing environment
Linux kernel 2.2.17
PIII 750MHz, 256MB RAM, IDE disk
configure option: configure --enable-multibyte=EUC_JP or configure
postgresql.conf settings(other than default):
max_connections = 128
shared_buffers = 1024
wal_sync_method = open_sync
deadlock_timeout = 100000
pgbench options:
-s 2 (initialization)
-t 10 (benchmarking)
--
Tatsuo Ishii
Attachments:
Tatsuo Ishii wrote:
I did some benchmarking with/without multibyte support using current.
...
(2) pgbench
With multibyte support(first column is the concurrent user, second is
the TPS):
...
32 95.947363
64 92.718780
128 61.725883Witout multibyte support:
...
32 92.283645
64 86.936559
128 87.584099
Do you have any theory why multibyte passes non-mb at 128 ?
Some subtle timing thing perhaps (or just bad luck for non-mb at 128)?
-----------
Hannu
On Thu, Sep 27, 2001 at 02:22:07PM +0900, Tatsuo Ishii wrote:
I did some benchmarking with/without multibyte support using current.
(1) regression test
With multibyte support:
9.52user 3.38system 0:59.27elapsed 21%CPU (0avgtext+0avgdata 0maxresident)kWithout multibyte support:
8.97user 4.84system 1:00.85elapsed 22%CPU (0avgtext+0avgdata 0maxresident)k
It's nice.
Can you try it for old 7.1? I should like see some improvement between
release:-)
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
It's nice.
:-)
Can you try it for old 7.1? I should like see some improvement between
release:-)
Not sure if it's meaningfull since new regression test cases might be
added for current?
--
Tatsuo Ishii
With multibyte support(first column is the concurrent user, second is
the TPS):...
32 95.947363
64 92.718780
128 61.725883Witout multibyte support:
...
32 92.283645
64 86.936559
128 87.584099Do you have any theory why multibyte passes non-mb at 128 ?
Some subtle timing thing perhaps (or just bad luck for non-mb at 128)?
May be or may not be. I was anxious about the load module size and
thought it might stress the memory. So while running pgbench I checked
the memory usage using vmstat. However it showed no excess page
in/page out...
--
Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
I did some benchmarking with/without multibyte support using current.
(1) regression test
(2) pgbench
pgbench unfortunately seems quite irrelevant to this issue, since it
performs no textual operations whatsoever. It'd be interesting to
modify pgbench so that it updates the "filler" column somehow on each
update (perhaps store a text copy of the new balance there), and then
repeat the tests.
regards, tom lane
pgbench unfortunately seems quite irrelevant to this issue, since it
performs no textual operations whatsoever.
Yup.
It'd be interesting to
modify pgbench so that it updates the "filler" column somehow on each
update (perhaps store a text copy of the new balance there), and then
repeat the tests.
Maybe. I'm not sure if it would show significant differences though.
Anyway, what I'm interested in include:
o regexp/like/ilike operations
o very long text handling
I'll come up with more testings..
--
Tatsuo Ishii
I did some benchmarking with/without multibyte support using current.
(1) regression test
(2) pgbenchpgbench unfortunately seems quite irrelevant to this issue, since it
performs no textual operations whatsoever. It'd be interesting to
modify pgbench so that it updates the "filler" column somehow on each
update (perhaps store a text copy of the new balance there), and then
repeat the tests.
Ok. Here is the result:
Without multibyte:
1 50.190473
2 65.943052
4 74.908752
8 62.589973
16 87.546988
32 94.448773
64 88.019452
128 64.107839
With multibyte:
1 47.473237
2 61.435628
4 83.047684
8 95.556846
16 92.157352
32 95.879001
64 91.486652
128 66.926568
a graph is attached.