Thread: 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
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
> 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
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
> > 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
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) 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.