Ever since LR 7.3 introduced the new develop preset format, it takes O(n^2) time for a plugin to access n develop presets. Some users have 5K, 10K, or 15K presets, and it can take minutes for a plugin to access all of the presets:
for _, folder in ipairs (LrApplication.developPresetFolders ()) do
for _, preset in ipairs (folder:getDevelopPresets ()) do
...Users think the plugin has crashed or hung! While having 10K presets may seem unusual, there's no excuse for LR to take minutes to return all the presets.
Here's how fast my LR 14.3.1 / Mac OS / Macbook Pro M2 Max (2023) loads presets versus the total number of presets:
Note that Excel has fit an n^2 curve to the data with R^2 = 0.9998, a nearly perfect fit.
I'm developing a new plugin that would like to access all the presets, and I know from previous experience that users with several thousand presets or more are not that rare. It would take about 25 seconds to load 5000 presets and 100 seconds to load 10,000 presets.
Most likely, LR is storing all the presets in all the folders ("groups") in a single flat list. When the method folder:getDevelopPresets() is called, it scans the entire list for presets with a matching group. A correct implementation is obvious: Use a hierarchical representation, with a list of folders, each folder with a list of presets. Instead of 25 seconds to load 5000 presets, it would take an estimated 0.15 seconds.
I first reported this in 2019, with a 2019 Macbook:
It was closed in 2023:
"This is an older bug that is no longer reproducible under the current Operating Systems and Lightroom versions. We are closing this bug. Should a similar bug arise, please create a new bug report."
(That notification never arrived in my email for some reason, so I never tested it in 2023.)
Code for measuring the load time is in that report:
My current computer (a 2023 Macbook) loads presets about twice as fast as the 2019 Macbook, indicating there has hasn't been any algorithmic change to the LR/Camera Raw code.
3
Replies
AdChoices