Permlink Replies: 4 - Pages: 1 - Last Post: 23-May-2014 12:49 Last Post By: karlmistelberger
gbonne

Posts: 2
Registered: 15-Jun-2012
Tuning jAlbum for best performance and memory usage
Posted: 12-May-2014 23:15
  Click to reply to this thread Reply
Hi there. First a little intro about what I do for living besides being passionate for photography and using a registered version of jAlbum.

I work as an IT systems engineer for a multinational insurance company. I support application platforms of all kinds on many different operating systems. Lately I have been tuning Java memory allocatyion and usage as well as optimizing garbage collection on an enterprise level product.

Basically, I know pretty well some stuff I will be talking about right now.

Why I write this little post

As most of you I once encountered the dreaded out of memory errors using jalbum in the past. That was the first time I started to look for initial tuning. The obvious Xms & Xmx parameters saved the day at the time.

Nevertheless I became less happy with the performance and started to look for some more in depth Java tuning.

This is to share my findings and help the community progress with what I found so far being the best tool to create appealing photo album web pages.

Let's get to it now

First of all I am going to tell you to do what the developpers do not recommend. It is using a different JRE than the one that comes with jAlbum. For two reasons.
1) Regularly security updates to the Java runtime Environment are issued (that is JRE). And it is good habbit to follow security updates. One cannot smoothly and safely update the included JRE (it is possible but not so simple).
2) By now (I mean current day) practically everybody has a 64 bit Windows and at least 4GB RAM. Pictures can take a lot of space when being handled in memory... Let's use all of that and go beyond the 32-bit JRE. This means that if you have a 32 bit windows then this article does not apply to you.

How to go about doing so. Well plain and simple. Find the latest Java runtime from the web directly from Oracle (who took over Sun). Simply Google "download java". Then click around the site to find a 64 bit version standalone java runtime installation. Personally I use Java 1.7 on jAlbum 11 (I mentionned that I registered right? Well I did not registered twice just to get jAlbum 12 so for now I stick to 11).

Run the Java runtime setup... You know, "next next next" and that is it.

Now how about to make jalbum use that? Well very easy, the jAlbum developpers included a batch file named StarJAlbum.cmd" that you will find in your jAlbum installation folder (usually "C:\Program files (x86)\jAlbum" by default). The beauty is that the batch uses the standard system default JRE installation (the latest one installed). Create a shortcut to start that Batch instead of using the shortcut created by the JAlbum installer.

However this file has to be modified. Open it with Notepad and change the line that starts with 'start "JAlbum" /D ....'.
Change it to look like so:
start "JAlbum" /D "%~dp0" javaw.exe -Xmx2500M -Xms2500M -XX:MaxPermSize=256M -XX:NewSize=800M -XX:MaxNewSize=800M -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:+DisableExplicitGC -jar JAlbum.jar

Now this should be nice if you have a 64 bit Java Runtime being installed as your last Java Runtime setup. If you now go and install a 32 bit JRE (like when your browser wants an update) then this will mess things up, make sure you reinstall the latest 64 bit JRE as the last setup on your system.

This will allow JAlbum to use 2500M RAM in total (actually a tiny bit more for JVM management) and divide it into 800M Young Gen space (the fast working memory) and 1600M Old Gen (large slow objects and "to be held for removal" stuff).

-XX:DisableExplicitGC will also prevent JAlbum to trigger garbage collections by code. I discovered that the coders use a lot system.gc() to trigger GC's... Now a GC (short for Garbage Collection) is a java operation that cleans up and reorganizes the memory in your java application. This goes together with what we call a "stop the world", or basically it freezes the application till done. The JRE does this on its own using internal algorythms. If your application does some extra GC's you will be forcing a "freeze" when probably not needed. this may be good for debugging reasons but not for a production running application. I found that JAlbum, when left on its own, does this way too much while one simply navigates his pictures in the GUI. Almost at every mouse click. Getting rid of this saves a lot of time freezes and presents a much smoother experience while working in your files.

-XX:+UseParNewGC is somekind of real time parallel way of doing small GC's in the Young Gen memory space. As we all have at least dual core CPU's with hyperthreading we can benefit from this as soon as we have 4 logical cores. This will ensure that the working memory will be kept optimized and the GC's occuring in there and from there to the old gen space will be very fast.

Why NewSize 800 and what the heck is SurvivorRatio.... Well this post is not really meant to be an entire insider on Java Runtime internals.... You can go and search technical articles about all this on the net. But basically with the figures presented I make the core working memory being 640MB and the Survivor space 80MB (the Survivor space is doubled so we have 640 + 80 + 80 = 800MB Young Gen i.e. NewSize). I figured by rough estimation that uncompressed images in memory could take up to a few hundred MB's add to that other objects for JAlbum plus moving more than one iamge around in memory and ... tada my starting point was 500MB... By trial and error and analysing GC behavior with the appropriate tools I found that 640MB was the best minimal "Eden Space".

That way most of the processing of loading the images in memory and generating the albums is entirely done in Young Gen memory without the need to interrupt each picture with a GC. I.e. An image can be processed entirely in one go without being GC'ed several times.

-XX:MaxPermSize=256M is what 64 bit JRE's like to have as a minimum. 128M can be fine for 32 bits. PermSize contains memory management objects. I found JAlbum not to use excessive much of these (max 46M during my tests) and 256M ought to be fine. If you do not specify this on an out of the box 32 Bit JRE then you may still encounter "out of memory" even with Xms/Xmx set to 1500M.

What If You have More RAM than 4GB
You can always increase even more. But beware that the more Xms/Xmx the more a GC will need to handle objects and the longer the GC will take. Thus undoing the gains in performance.

Personally I have a 12GB system. I only use pictures in my albums and my highest resolution camera is 16MPixels. The longest full GC's encountered where of the order of 0,18s during album generation. During navigation the longest was probably like 0,08s. You do not even feel that.

If you have a D800 and all your images are 36MPixels then you milage will probably vary. I am willing to redo GC analysis with a set of pictures that are much larger in size. However I have none... Feel free to share some with me and I'll do the thing again.
If you want to enlarge NewSize and MaxNewSize... Beware that it should be no more than like a third of your total heap (Xms/Xmx). If you want to use like 1024M for NewSize then make sure you also increase Xms and Xmx to 3096 for instance.

Never allocate more Xmx than 75% of your total RAM! Because when you start making Windows swap memory into the paging file then you are defeating the purpouse.
Also if you do have increased Xmx to 75%of your Windows memory then do close all other applications before using JAlbum.

That's about it. Enjoy your smoothest JAlbum experience ever.
jGromit

Posts: 33,750
Registered: 31-Jan-2006
Re: Tuning jAlbum for best performance and memory usage
Posted: 13-May-2014 00:43   in response to: gbonne in response to: gbonne
  Click to reply to this thread Reply
Just out of curiosity, why not Java 1.8.0_05?
gbonne

Posts: 2
Registered: 15-Jun-2012
Re: Tuning jAlbum for best performance and memory usage
Posted: 13-May-2014 08:30   in response to: jGromit in response to: jGromit
  Click to reply to this thread Reply
Good point.

For one I was not aware that 1.8 was already publicly available.

It may be worth testing. In the past the JAlbum developers recommended sticking to 1.6, which I did not do. There were some minor aesthetic issues admittedly but these have vanished for some time now. So having used 1.7 for over a year now I can safely say that JAlbum runs well on 1.7.

So yes, if you want to test and experiment with jre 1.8 please do so and report your results.

Myself I prefer to stick to the stable, tried and proven working jre 1.7 as my priority is now to have a stable and reliable JAlbum to be productive on my photo gallery. In other words my priority is now using JAlbum without issues instead of experimenting with it.
jGromit

Posts: 33,750
Registered: 31-Jan-2006
Re: Tuning jAlbum for best performance and memory usage
Posted: 13-May-2014 10:23   in response to: gbonne in response to: gbonne
  Click to reply to this thread Reply
gbonne wrote:
For one I was not aware that 1.8 was already publicly available.

I didn't stumble on it until I installed Netbeans 8.0. And it appears that there is only a 64-bit version of 1.8, so unless you visit java.com with a 64-bit browser, it isn't readily offered up to you (and 64-bit browsers are virtually unknown).
karlmistelberger

Posts: 875
Registered: 5-Dec-2013
Re: Tuning jAlbum for best performance and memory usage
Posted: 23-May-2014 12:49   in response to: gbonne in response to: gbonne
  Click to reply to this thread Reply
gbonne wrote:
It may be worth testing. In the past the JAlbum developers recommended sticking to 1.6, which I did not do. There were some minor aesthetic issues admittedly but these have vanished for some time now. So having used 1.7 for over a year now I can safely say that JAlbum runs well on 1.7.
I found that jAlbum does well with my default system. The only change I made was increasing to java -Xmx2000m Lower values work well, but are somewhat slower.
Myself I prefer to stick to the stable, tried and proven working jre 1.7 as my priority is now to have a stable and reliable JAlbum to be productive on my photo gallery. In other words my priority is now using JAlbum without issues instead of experimenting with it.
That's what I am practicing too.

Best performance is obtained with lots of real memory. My box got 16 GB. jAlbum uses 2.3 GB real memory and 4.7 GB operating system cache when building a large album. The Intel Coreā„¢ i3-4130 has only two cores, but hyperthreading works perfectly. So I get 400% CPU load when processing images with each of the four threads being kept busy at 100%.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums