Alberto,
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
Generally, using serialization is probably ok, but you would need to
make sure that serialized data is always saved from a single thread
(probably trough some manager abstraction, and maybe even
asynchronously, aggregating saves for multiple updates)
regards,
Eugene
Alberto Gimeno wrote:
> The current implementation of the cache does not meet my personal
> expectations. I think that queries are fast but inserting and updating
> the cache is very slow. Maybe the embedded database is a bottleneck.
>
> I'm thinking about to implement the cache using Java serialization.
>
> In the current database structure I use a "files" table to store the
> branches information and I give a unique ID to each file. That ID is
> shared between a file and its branches. This is, one ID = one graph.
> Every file path involved in the graph has the same ID in the database.
> So I think that maybe it could be possible to have:
>
> * One file for storing the "files" information (branches and unique IDs).
> * One file per file ID. All the information to show a graph would be
> in one of these files.
>
> Those files would be written and read using serialization.
>
> I'm not sure. Before making a new implementation I can do some things
> to improve the performance. I can try to find if there is some query
> against the database especially slow and fix it (for example, a query
> needs an index). And I can try to implement the cache using batch
> updates. But I would like to know your opinions.
>
> Nevertheless making a new implementation using serialization won't
> take me much time. Probably a few days.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: dev-help_at_subclipse.tigris.org
>
>
---------------------------------------------------------------------
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:01:27 CEST