Thread Locked This thread is locked - replies are not allowed.



Permlink Replies: 3 - Pages: 1 - Last Post: 21 Oct 22, 14:38 Last Post By: davidekholm
davidekholm

Posts: 3,620
Registered: 18-Oct-2002
jAlbum 29.0.2 service release
Posted: 18 Oct 22, 19:44
We're releasing a silent service release of jAlbum 29 tomorrow. It has the internal version number 29.0.2

Fixes:
  • Fixed "Metadata read only" error introduced with v29
  • Improved page processing speed. Less IO
  • Improved lifeboat.zip generation speed. (3x on a networked drive)
  • Fixed IOException caused by calling AlbumObject.getVars() on template file from an external tool
  • Minor bug fixes
  • Added profiling information to spot performance issues
  • Developers: Added new "Profiler" class to print profiling data
  • Made version available for Mac users running older OS X versions (High Sierra)
  • Groovy skin UIs now work better (one can omit "public" access modifier now)
  • jAlbum now informs the user when generating the lifeboat file during the album build process (previously it has looked like jAlbum was hanging while processing the last image)

Installers:
Windows: https://jalbum.net/download/jAlbum-install.exe
Mac OS X (Current): https://jalbum.net/download/jAlbum.dmg
Mac OS X High Sierra: https://jalbum.net/download/jAlbum-java14.dmg
davidekholm

Posts: 3,620
Registered: 18-Oct-2002
Re: jAlbum 29.0.2 service release
Posted: 19 Oct 22, 12:56   in response to: davidekholm in response to: davidekholm
We've now updated the official download archives so everyone is getting v29.0.2 now. I advice you to reinstall jAlbum using these archives.

v29.0.2 also features an embedded profiler that can help detect performance issues. After an album build, you can open the system console and issue the following (Groovy example)
Profiler.instance
This will print profiling info for various possible "cpu hotspots". The profiler keeps track of # of calls and real time spent in the respective code section.

Here's a printout from making "Sample Project":
             FileFilters.saveImage:    38 calls       1,96s
             FileFilters.loadImage:    19 calls      1,477s
                              init:     1 calls      1,459s
        HardwareSmoothScaler.scale:    37 calls      1,043s
          AlbumBean.makeIndexPages:     1 calls      0,581s
          AlbumBean.processFilters:    93 calls      0,384s
                   Create MediaRSS:     1 calls      0,224s
       AlbumBean.registerVariables:    19 calls      0,069s
                    copy res files:     1 calls      0,046s
     AlbumObjectImpl.getXmpManager:    17 calls      0,045s
       AlbumObjectImpl.getMetadata:    18 calls      0,044s
     AlbumObjectImpl.getProperties:    26 calls       0,03s
JAlbumUtilities.getDeepCameraDates:     1 calls      0,029s
       RecoveryTool.createLifeboat:     1 calls      0,028s
     FileFilters.getBasicImageInfo:    18 calls       0,02s
        AlbumObjectProperties.load:     3 calls      0,017s
       AlbumBean.countChangedFiles:     1 calls      0,004s
   JAlbumUtilities.countCategories:     6 calls      0,004s
     AlbumBean.getFolderProperties:     1 calls          0s
                             Total:   302 calls      7,464s
Don't try to map "total" time to real total time. We aren't profiling each and every code section. New code sections may be introduced to better cover the full time spent during album builds.

Skin developers that wish to get a better understanding of where time is spent can add profiling info to any method or code section. There are two ways, using an explicit label and automatic label. Here's an explicit label:
import net.jalbum.util.*;
import static net.jalbum.util.Profiler.Sample;
 
try (Sample _s = Profiler.profile("Sleeping")) {
	Thread.sleep(1000); // Stuff to profile here
}

Now, printing the profiling info will generate
Sleeping:     1 calls      1,003s

You can reset the profiler using
Profiler.instance.reset()
You can also omit the label, like this
import net.jalbum.util.*;
import static net.jalbum.util.Profiler.Sample;
 
try (Sample _s = Profiler.profile()) {
	Thread.sleep(1000); // Stuff to profile here
}
The profiler will then use the name of the calling class and method as label.

Multiple threads
If profiled code is being called from multiple threads, then the timing information corresponds to real time, not cpu-time (thread-time).
AndreWolff

Posts: 1,158
Registered: 14-Dec-2007
Re: jAlbum 29.0.2 service release
Posted: 21 Oct 22, 09:25   in response to: davidekholm in response to: davidekholm
David did you see this message?
davidekholm

Posts: 3,620
Registered: 18-Oct-2002
Re: jAlbum 29.0.2 service release
Posted: 21 Oct 22, 14:38   in response to: AndreWolff in response to: AndreWolff
No, but now I've replied
Legend
Forum admins
Helpful Answer
Correct Answer

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