9:12 p.m.
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)
6:07 a.m.
Just a clarification, I presume "old imp" == "JDBCCacheLoader" and
"new impl" == "RedcdRecJDBCCacheLoader", as per your class diagram?
Interesting to note that even in the case of a shallow tree (say, not
more than 3 nodes deep) there still is a considerable improvement in
the put() operation at least, even though remove() and loadState()
don't produce that great an improvement.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
6:09 a.m.
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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
6506
days inactive
6507
days old
jbosscache-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Manik Surtani -
Mircea Markus