Обсуждение: multibyte performance

Поиск
Список
Период
Сортировка

multibyte performance

От
Tatsuo Ishii
Дата:
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

Re: multibyte performance

От
Karel Zak
Дата:
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)k
> 
> Without 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


Re: multibyte performance

От
Tatsuo Ishii
Дата:
>  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


Re: multibyte performance

От
Hannu Krosing
Дата:
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.725883
> 
> Witout 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


Re: multibyte performance

От
Tatsuo Ishii
Дата:
> > With multibyte support(first column is the concurrent user, second is
> > the TPS):
> ...
> > 32 95.947363
> > 64 92.718780
> > 128 61.725883
> > 
> > Witout 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)?

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


Re: multibyte performance

От
Tom Lane
Дата:
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


Re: multibyte performance

От
Tatsuo Ishii
Дата:
> 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


Re: multibyte performance

От
Tatsuo Ishii
Дата:
> > 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.

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.