Re: [Subclipse-dev] Revision graph and cache implementation

On Tue, Jul 8, 2008 at 11:24 AM, Alberto Gimeno <gimenete_at_gmail.com> 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.

Doesn't serialization open the door to memory problems? If I have a
massive cache and you want to read it all into memory it seems like
that would be a problem.

If querying is fast, but writing is slow, then indexes are not likely
the problem. Although it is possible that maintaining the index while
writing the data slows it down. You could experiment with dropping
all indexes before you write and then add them back when you are done.

You could also try another database like HSQLDB.

I think you should stick with a database.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org