From: <leg...@at...> - 2003-12-31 20:40:26
|
The following comment has been added to this issue: Author: Juho Snellman Created: Wed, 31 Dec 2003 2:40 PM Body: Perhaps some details on the testcase might explain why such excessively large amount of time is spent assembling the objects back from the cache. It doesn't seem very much like a special case to me. First of all, there's a tree of Nodes (about 500), that have a parent reference and a lazy Set of child-Nodes. Each Node also has a lazy Set of Documents associated with it (and the Documents have a reference to the parent Node). The Documents (a total of 600 in this test) also have a bit of tree-structured data attached to them (a total of less than 2000 objescts worth of these). This tree is also modeled using parent reference + lazy Sets of children. The amount of objects isn't very large, so they all fit into the cache comfortably. Once everything is in the cache, loading any object will also result in everything being assembled at once. This is a web application, so for every request we need to do this again. I did some more digging in the profiler output (unfortunately the profiler isn't very good at reporting the aggregate time spent inside a function when recursion is involved). As far as I can tell, the problem is that these sorts of "recursively do something to everything" operations magnify even the smallest overheads out of proportion. For example, just calls to the Logger's isTraceEnabled()-method take up 10% of the whole program's execution time! One call might be really cheap, but it ends up being called 30000 times/web request. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-587 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-587 Summary: Lazy collections not lazy when used with second level cache Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1.1 Assignee: Reporter: Juho Snellman Created: Tue, 30 Dec 2003 8:53 AM Updated: Wed, 31 Dec 2003 2:40 PM Environment: Hibernate 2.1.1 ehcache Description: When an object is loaded from the second level cache, any of its collections that are found from the cache are immediately initialized. This happens for both lazy and non-lazy collections. These initializations then cascade on to the contents of the collection, and their child-collections. For a sufficiently large and interconnected graph of objects this results in a disastrous performance loss when caching is enabled. In my particular case a test enabling caching increases the runtime of a test from about 12 minutes to over 40 minutes. In the latter case SessionImpl.getCachedCollection() takes up 68% of the runtime. Disabling caching only for collections brings the runtime back down. Aside from the performance issue, it seems to me that initializing lazy collections is also conceptually wrong. Shouldn't laziness mean "no work is done unless it's neccessary", instead of "nothing is fetched from the DB unless it's neccessary"? I'm pretty sure this didn't happen with Hibernate 2.0 and JCS. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |