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-ex...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev