db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: ArrayInputStream and performance
Date Wed, 29 Nov 2006 22:20:14 GMT
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.

Dyre.Tjeldvoll@Sun.COM 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?
> 


Mime
View raw message