One option we use on our uPortal installs is to enable -XX:+UseCompressedStrings
It requires a bit more CPU but we are generally memory bound and not CPU bound. The description reads "Use a byte[] for Strings which can be represented as pure ASCII. (Introduced in Java 6 Update 21 Performance Release)" for many applications, even those used in other locales, a majority of the strings just use the ascii charset which only needs 1 byte/char See http://thevirtualmachinist.blogspot.com/2010/12/xxusecompressedstrings-explained.html I realize this isn't a general solution but might be interesting as a suggestion for people to look at if they are running into memory issues. -Eric On 5/16/12 11:28 PM, Hardy Ferentschik wrote: >> Its been proposed a number of times to instead generate just a single >> loader for loading that number of items. This would mean generating a >> single SQL statement that has parameter holders for the full batch size >> and then somehow "filling out" the empty slots when the number of things >> to load is less that 16. If this could be made workable across all >> dialects, I personally think it would be the best approach as it >> probably gets close to the start up sizings you claimed but would never >> grow beyond that. > +1 if it is possible it sounds like the best way of doing it > > --hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
