There can be little doubt that version 7 of A Better Finder Rename was a giant step ahead for the product in almost every respect.
The major area where that was perhaps not the case was in performance terms. As long as you are renaming only a couple of hundred files, performance is more than adequate, but for people dealing with many thousands of files the performance of version 7 was a step backwards. This came as a late and unpleasant surprise, because version 7's code base is just so much cleaner and more streamlined than that of version 6, which was beginning to show its age.
This is why I have taken some time out from developing new features to get to the bottom of this performance problem. This investigation has detected a couple of facts:
- sorting is a real killer, especially when mp3 or exif tags are involved
- feedback is just as important as raw speed
- there is no way around the fact that doing the same thing one thousand times takes one thousand times longer than only doing it once
In this first iteration of getting a faster, nimbler renamer, I have concentrated on these points:
- the program now only does the bare minimum processing while you're honing your settings. This makes for a fast and responsive preview even with tens of thousands of files. The preview only displays the first 250 items (that's around 10-15 screenfulls), enough to give you a real good impression of what the end result is going to be, not enough to bring the preview to a grinding halt. The heavy duty processing starts only once you hit the "OK" button.
- everything that can possibly be cached is cached. EXIF dates and the like are only read once and the system remembers them without re-reading them every time. This can result in a factor 10-100 performance improvement on large sorts.
- provide feedback on what's happening. Previous versions just went off to do their thing, leaving you to wonder what, if anything was going on. The new version provides a progress dialog that shows you how much work is actually going on behind the scenes and how much longer is going to be required to do it.
- I have found and eliminated a couple of bottlenecks in the program that result in improved overall performance
As a result of those changes, version 7.2.5b1 feels and behaves completely differently when confronted with huge renames. Yes, doing 2000 files will still take twice as long as renaming 1000, but the preview remains responsive and it's fun to see your Mac race through ten thousand name computations, sorting, validation, etc.
The downside of these improvements is that I've had to make fairly hefty changes to the structure of the program, including multi-threading its execution. Multi-threading, in particular, makes the complexity of a program explode because it causes all kinds of potential error conditions: deadlocks, racing conditions, etc.
This is why I've decided to release a beta version first to validate that my changes haven't broken anything that used to work just fine.
You can download the beta from the product download page . I trust you will find it a big improvement with large file sets.
Please do report any problems you may find; it's tempting to think "somebody else will or has already alerted the developer", but all too often nobody does. I can only fix bugs I know about and the best way of getting rid of them is to report them directly to me at: reiff@publicspace.net