Mark Phippard 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:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html?revision=HEAD
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.releng.basebuilder/plugins/org.eclipse.test.performance.ui/readme.html?revision=HEAD
>>
> 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.
Right. The perf framework is basically the same thing, but comparing
system.out prints it leaves recording of the perf test execution that
can be compared and viewed later. For system.out things you would need
to do it by hands.
regards,
Eugene
---------------------------------------------------------------------
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 19:43:05 CEST