A discussion on the list would be great. Can anyone post a complete
test run with exact description of test, and flat and hierarchical
results performance monitor reports. It is interesting if info has
both number of calls and time.
I was starting to look at:
http://wiki.apache.org/db-derby/Derby1961MethodCalls
I find it really useful to start looking top down at number of
operations per test rather than bottom up. So for instance,
some things jumped out:
o derby.iapi.services.io.ArrayInputStream.setPosition 58.4240
At first I was expecting this to be something like 1 per row + 1
per column. I assume it got big through btree search - hierarchical
data would show. It might be interesting to know btree overhead vs.
heap overhead. maybe btree compare can be optimized?
o derby.iapi.store.raw.ContainerLock.isCompatible 14.7802
This one looks wierd, I don't even see it in the
cleanup_flat_profile.txt posted with DERBY-2118. I sort of
expected 1 call for the btree and one call for the heap. Maybe
this is a multi-user run with a long list of table locks, if so
maybe this can be optimized by somehow grouping the locks so that it
is not necessary to compare to each one?
The
description on the wiki doesn't say much about the environment
the test was run under (ie. # processors, speed processors,
write-sync state of disks, how many disks, was log/data on same disk?)
Also I do encourage those interested in looking at changing the network
server code to look at these performance results. This code is new to
Derby and I am not aware of much previous work in the network server
performance area so there is likely some low hanging fruit there.
Previous to open source most tuning concentrated on embedded, single
user performance, ramped up JIT, cached data, compiled statement
performance.
[EMAIL PROTECTED] wrote:
So I would like to encourage you and Mike and anynone else to look at
Derby's performance. Do your own comparison with other databases using
the vm you prefer. Let us know what the results were. If performance
isn't a problem let me, and everone else that seems to think so, know
what we're doing wrong. And if it turns out that performance could be
better; do your own profiling. Propose some intelligent changes based
on what you see. Maybe I or someone else can implement it based on
your guidelines?
