My work on v29.0.4 service release has turned into a new beta because I've been reworking several internals in order to cut album making time further. I now see typically 1.3x - 1.4x faster album builds (page processing only), but one networked project* now scores up to a whopping 6x faster build times!

This dramatic speed improvement is due to two factors:

• v29.1 now uses 24 parallel IO threads for grabbing metadata. Earlier versions didn't use more IO threads than CPU cores. When IO and not CPU is the bottleneck, we should use far more threads.
• v29.1 is more conservative rewriting resource files that aren't updated. Earlier versions used to clear all files from the "res" folder and re-write them. Over the AFP network protocol, such writes have a dramatic negative impact on the network layer disk cache, impacting further IO operations negatively
• Earlier versions attempted to create directories even if they existed.This also ruined the network layer disk cache.

Tests: *
Computer: MacBook Pro 2015 (3,1 GHz Dual-Core Intel Core i7), 4 core CPU.
OS: Mac OS "Monterey".
Network: 802.11ac wifi (580 MBit/s)
NAS: Synology DS220+
Project: Tiger skin. 356 12 MPixel images mounted on a NAS, accessed via AFP (Apple File Protocol).

Timings, building the gallery 3 times after each other (page processing only):

v28.1:
1:st run: 1m 9,644s
2:nd run: 52,056s
3:rd run: 51,151s

v29.1 beta:
1:st run: 26,059s (2.6x faster)
2:nd run: 10,117s (5x faster)
3:rd run: 8,074s (6x faster)

On windows, using the SMB network protocol, I don't get the same dramatic improvement. The same gallery builds in 53,887s on v29.1 beta vs 1m 2,694s on v29.

Further changes:

• More detailed profiling information (evaluate Profiler.instance in system console to see)
• Uses up to 8 instead of 4 CPU cores for image processing
• Prints status info during album builds for file attribute reading too

Get the beta by replacing lib/jalbum-core.jar with this one:
https://jalbum.net/download/beta/jalbum-core.jar

Something I've wondered about.... I probably already know the answer, but....

If the user chooses not to include photographic and xmp data in generated pages and images, and chooses only jAlbum as the comments source, and also chooses No IPTC as the title source, what metadata is the process actually reading? Could this be bypassed? It clearly takes quite a bit of time.

Jeff, I appreciate if you run some performance tests on v29 vs 29.1 too. Different environments causes somewhat different behavior. You can execute Profiler.instance to see detailed profiling info.

A bit later - I'm a little preoccupied at the moment. Moving from a 2016-vintage Galaxy S7 (Android) to a shiny new iPhone 14 Pro (iOS), and also switching providers (but keeping my phone number). So far, not as bad as I thought it might be. Less than 24 hours, and I think I'm pretty much there.

Still some customization that I'll want to do, and other than shutting off the stupid HEIC default ("Gee, let's use a format that not even our own browser can display!"), I haven't even begun to explore the camera.

I was planning this move, but then got a bit of salt water on the S7 at the beach last week. Dire warnings about moisture being detected, hit-or-miss charging, and the occasional failure to detect the SIM card. It's actually stabilized quite a bit, but is clearly destined for the cellphone graveyard.

And the news doesn't get any better if I drop back to a BeanShell version of Neptune, and then run trials between v28.1.5 and v29.b3 (I can't run current Neptune with v28). Again, there's virtually no difference in album build time between the two.

But the worse news is that on a pure, no-image-processing rebuild, the BeanShell version of Neptune is about 20% faster than the Groovy version. Slow parsing? It's almost irrelevant, of course - 1.6 seconds vs 2.0 seconds.

Processing all of the images pretty much wipes out that difference (no surprise), since the image processing is where all the time is.

Hello,

I hope you all won't mind a question, though all this is waaay beyond me it is very interesting indeed to read about the things you are doing. It's very technical and quite deep.

But I have noticed since using jAlbum v29 that during making my albums, the 'initializing' phase right at the start of the process takes a lot longer than it did in all the other versions of jAlbum that I can remember.

So I was wondering, is this something that you expected to see ?

All is working unbelievably well though, just sometimes I have to bite my bottom lip, step into an alien conversation, and ask...

I hope it's not a ridiculous question

Regards Peter

Hi Peter, it's actually so that we now pop up the progress dialogue faster, thereby showing the "Initializing" phase a longer time even though it should be as fast/slow as before

Approximate averages:

29.1b3: 38s
29.1b4: 36s

I'll have to think about what I want to do with those extra two seconds. Perhaps write a novel.