And to clarify again, re: compatibility, I presume you're talking about people running the JDBCCacheLoader being able to stop their cache, switch to the RedcdRecJDBCCacheLoader, start again and still have their persistent data valid?

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik@jboss.org
Telephone: +44 7786 702 706
MSN: manik@surtani.org
Yahoo/AIM/Skype: maniksurtani



On 2 Feb 2007, at 03:12, Mircea Markus wrote:

Hi,

Attached is a comparison between old and new impl on JDBC cache loading. Basically recursion was eliminated in the case of loadState and remove, and the put had a 50% optimization. All other operation are more or less a single db call, so nothing can really be programmatically improved.

The second image contains the design. Any comments are extremely welcomed :)
Nothing is committed yet on CVS.

An open issue is the backward compatibility - working on that.

Cheers,
Mircea

P.S.
How I've tested the performance (phps more easy to understand it from code :-)
 a tree with a TREE_DEPTH depth is created. Each node in the tree has a CHILDREN number of children. By default I've used TREE_DEPTH=7 and CHILDREN=3 which gave a total number of 3280 children. A node is selected at each depth from disjunct  subtrees.  ( i.e. in the benchmark used 7 nodes are selected). On all those nodes a certain operation is performed: loadState, remove etc. For benchmarking the put operation, the in memory tree nodes are Collections.shuffle(List<Fqn>), then they are (randomly) added to the database/classLoader.put. This procedure was repeated sever times. Also additional testing was performed in the case of put for deep trees (100 - 200 nodes)



<performance_comparison.PNG>
<design.png>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev