Re: tuning/profiling
От | Kevin Grittner |
---|---|
Тема | Re: tuning/profiling |
Дата | |
Msg-id | 435671DD0200002500000141@gwmta.wicourts.gov обсуждение исходный текст |
Ответ на | tuning/profiling (Ken Geis <kgeis@speakeasy.net>) |
Ответы |
Re: tuning/profiling
(Dave Cramer <pg@fastcrypt.com>)
|
Список | pgsql-jdbc |
Ken, If you're going to be running tests and benchmarks anyway, you might want to consider replacing the synchronized collections (Vector and Hashtable) with their unsynchronized counterparts (ArrayList and HashMap). While each synchronized block only costs about one microsecond (in benchmarks I've run), there is a potential hidden cost to them -- they may prevent some of the more aggressive optimizations available to the JIT. In case you haven't run into this issue, each thread can keep a cached copy of any variable it uses. It does not need to re-read the variable from shared memory except when it references the variable after the thread has entered any synchronized block after the last read. It does not need to write any modifications to shared memory until it leaves a synchronized block. The profiler could show this access to shared memory as a cost far from where the synchronized block itself, and it could affect variables that have nothing to do with the collections. Synchronizing on any object affects all cached variables. This is not hypothetical; I have seen these JIT optimizations in production environments. As far as I'm aware, the driver is not thread-safe anyway (and is not required to be so by the JDBC spec) except for the Statement.cancel() method. One would have to pay special attention to that. Having said all that, you're more likely to get big gains by addressing whatever the profiler highlighted. -Kevin >>> Ken Geis <kgeis@speakeasy.net> >>> Hi. I just did some investigation into improving the performance of the JDBC driver. I want the best performance for my application, and I would love to be able to make PostgreSQL more competitive. I wrote a simple benchmark that would be doing an action common in my application (fetch ~11000 rows from a table with a date, four numeric(9,4) columns, and an integer.) I ran this through a profiler and found some hot spots. In the end, I was able to squeeze out at least 50% improvement with a small amount of changes to driver code. Before I submit patches, I must run my changes against the test suite and other benchmarks. Then I will break my patches into independent pieces. Some of my changes may be controversial because they may be less robust than current, but I am making some assumptions about the server protocol (like that date strings will never contain Unicode digits.) Does anyone have a benchmark they'd like me to run? I could run ECPerf, PolePosition, TPC-W, or Jdbcbench. Ken
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Andres OlarteДата:
Сообщение: Re: How to bulk load a schema using JDBC multiple times?