Not much has changed in 3.3 – except for performance….

Over the years I’ve heard from a few people using the plugin to sync metadata between far larger numbers of files than I really anticipated – not thousands but tens of thousands. They were finding that the plugin worked, but very slowly indeed.

So I had looked over the code and occasionally experimented with different approaches, but I didn’t want to risk fixing a plugin that wasn’t broken. After all, no matter how slow it may have been, it was always a lot faster than synchronising large amounts of metadata manually!

Earlier this year someone had reported that the slowdown wasn’t linear and suggested that processing bigger numbers of images made the plugin exponentially slower.

The Covid-19 lockdown and my low opinion of the UK government’s abilities to fight it gave me lots of home-time to mull over the problem, and the exponentially-slow performance theory did make a lot of sense. The code was written to allow for multiple occurrences of the target filename, so each source photo was being compared against each target photo, even after a match had already been found.

So my initial optimisation was rather inspired by how people often delete dating apps after meeting the perfect match. That’s the Unique Match option (right). With my test sample of 776 pairs of photos, it completes 4 times faster than the old method.

The second idea was a complete rewrite of the matching process, and there I had the benefit of 10 years’ more experience of programming in this environment. That’s the New Matching Process option, and with my test sample of 776 pairs, it completes 33 times faster than the old method. With more photos, the improvement should be even more noticeable.

My recommendation is to enable the New Matching Process, which is now the default.

Please test it carefully and let me know your thoughts. I’m not planning other changes to the plugin, but if you make a persuasive case….

 

I’ll also share my stats below: