User development, The document "JBossCachePerfAnalysis", was updated Feb 22, 2010 by Manik Surtani. To view the document, visit: http://community.jboss.org/docs/DOC-10279#cf Document: -------------------------------------------------------------- This is an experimental page to list potential bottlenecks or code inefficiencies we see in the JBC codebase.  The purpose of this page is that whenever we come across any (any we cannot fix on the spot) while in the process of development of other features/debugging/tuning, we should note it down.  These should, once analysed and solutions agreed upon, be converted into JIRA tasks.     || Description || Class(es) affected || JIRA task (if any) || Potential solution || | Connection pooling does not occurr when JBC used standalone, affecting the performance of JDBCCL | o.j.c.l.JDBCCacheLoader | http://jira.jboss.com/jira/browse/JBCACHE-802 | Use a pooling library (i.e. C3P0) for the standalone version | | Standard serialization is not performant and takes up far too much space | o.j.c.l.JDBCCacheLoader | http://jira.jboss.com/jira/browse/JBCACHE-879 | Reuse marshalling techniques introduced in JBC 1.4.0 and JBossSerialization for user types |     ---   Elias's list   * PojoCache.detach is wasteful. PojoCache.detach returns the existing value as part of the remove, which actually does a retrieve of the existing value, then the remove. Performance testing revealed that fetching data of the underlying TreeCache was done multiple times.   --------------------------------------------------------------