[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c...
]
Tyler Van Gorder commented on HHH-1258:
---------------------------------------
Having the Configuration object around is not as big a concern for us in the development
environment. Most of our machines have 2G of memory. And this is an option that would
ONLY be used in a development scenero.
So If I am hearing you correctly, the module would need to be made thread-safe and could
be ported to the 3.x code base (assuming we are not concerned with keeping the
Configuration object hanging out.)?
Perhaps if I have more time in the coming months I might try doing this properly. Max, if
you have time I sure would appreciate to pick your brain about which entry points into the
session factory implementation would require hooks to dynamically load the configuration.
Thanks.
startup time improvements
-------------------------
Key: HHH-1258
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.1 rc3
Reporter: Max Rydahl Andersen
Assignee: Max Rydahl Andersen
while doing some basic startup perf testing the following were found - this issue is
mainly to track what I find, and then fix it:
Initial tests where 100 classes, 30 sec for buildSessionFactory
setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for
buildSessionFactory.
(maybe we should autodetect which jdk we are running on and disable it per default for
1.4/1.5 - needs to validate runtime impact)
Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates
over all declared methods per property.
(alternatively we could cache/sort this list or make a more efficient implementation if a
class only contain default property accessors)
Other 20% of the time is done in net.sf.cglib related classes for build time
enhancement.
The rest of the time is Configuration creation (can be cached) and other iteration code.
(p.s. don't take the % numbers as hard values - these are definitly affected by how
many methods/classes you have; this underlying tests
is done on pojos with a "high" method count (approx 100)
--
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira