On Tue, Jul 8, 2008 at 12:00 PM, Eugene Kuleshov <eu_at_md.pp.ru> wrote:
> I'd suggest to run your current implementation under profiler (e.g. you can
> use YourKit, which work nicely with Eclipse, and they give away free
> licenses to OSS projects, so we can request one for Subclipse). Using
> profiler would also help you to quickly identify the biggest bottlenecks and
> see if there is an obviously quick fix for those.
> Another good practice is to create a performance test harness that would
> allow you to run your code and record concrete performance numbers. So, you
> would create a base line for your refactorings and can compare performance
> before and after. There is a performance framework in Eclipse, see
> org.eclipse.test.performance and org.eclipse.test.performance.ui plugins and
> corresponding documentation in those projects at:
There is nothing wrong with this solution, but it is probably a $100
solution to a $1 problem. I'd start with some system.out statements
and timings. We know that the fetching of Subversion log information
is a very big part of this process that we cannot do much to optimize.
So the question then becomes how much are we adding to this. Does
the calculation and database work take just as long/longer than the
log fetching? Could you make your DB insert statements call a no-op
function so that you take the DB out of the equation?
It ought to be possible to find the biggest bottlenecks fairly easily.
If you already know it is the DB inserts then look for things to
speed it up. I'd definitely suggest you try dropping the indexes and
recreating them after all the inserts are done.
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-07-08 18:16:11 CEST