AppleScript, Selections and Large Catalogs
It seems that using AppleScript to manipulate selected images in a large catalog can result in very very long wait times.
I observed a bit of this bevaiour, and so wrote a little AppleScript auto-profiler to make measurements with increasingly larger selections.
Using a catalog with 16249 images, on a late 2015 iMac with 4GHz I7 and 24 GB or RAM, external SSD, I got the following data..
If the selection contains 15400 images, and an Applescript sends "get count of selected images" to CaptureOne, the measured reponse time is an incredible 1250.077 seconds (just under 21 minutes). I had to set a "with timeout" large enough, otherwise AppleScript has a timout at the 2 minute mark.
With 300 selected images, the response time to the same AppleScript is 7.9 seconds.
With 4000 selected images, the response time passes the 2 minute mark.
The constant of proportionality is from 25ms per variant for small section to 35ms per selected variant.
The response to "count of every variant" ranges from to 43ms (300 selected) to 16.25 seconds (15400 selected)
These response times are much smaller for a 3000 image catalog (even with the same size selection). Therefore for catalogs much above 16000 images the delays, even for smaller selections will increase as well.
During the response time, Capture One is completely locked up, and won't respond to the keyboard or mouse, iy coninues calaculating the response even if Applescript times out, or the user stops the AppleScript.
In summary, for a large catalog, it's dangerous for Applescript to even ask how many images there are in the selection.
All the commands regarding selected images that I have tried so far take at least as long as "get count of selected images". There is one set that takes 2.5 times longer. "select" commands also take a very long time, I extrapolate that "deselect" will take about the same timee.
The only safe strategy that have come up with so far is to time the response to "get count of every variant". If the response is over 50ms, then there is a very large selection. But that is rather machine dependent I fear.
I observed a bit of this bevaiour, and so wrote a little AppleScript auto-profiler to make measurements with increasingly larger selections.
Using a catalog with 16249 images, on a late 2015 iMac with 4GHz I7 and 24 GB or RAM, external SSD, I got the following data..
If the selection contains 15400 images, and an Applescript sends "get count of selected images" to CaptureOne, the measured reponse time is an incredible 1250.077 seconds (just under 21 minutes). I had to set a "with timeout" large enough, otherwise AppleScript has a timout at the 2 minute mark.
With 300 selected images, the response time to the same AppleScript is 7.9 seconds.
With 4000 selected images, the response time passes the 2 minute mark.
The constant of proportionality is from 25ms per variant for small section to 35ms per selected variant.
The response to "count of every variant" ranges from to 43ms (300 selected) to 16.25 seconds (15400 selected)
These response times are much smaller for a 3000 image catalog (even with the same size selection). Therefore for catalogs much above 16000 images the delays, even for smaller selections will increase as well.
During the response time, Capture One is completely locked up, and won't respond to the keyboard or mouse, iy coninues calaculating the response even if Applescript times out, or the user stops the AppleScript.
In summary, for a large catalog, it's dangerous for Applescript to even ask how many images there are in the selection.
All the commands regarding selected images that I have tried so far take at least as long as "get count of selected images". There is one set that takes 2.5 times longer. "select" commands also take a very long time, I extrapolate that "deselect" will take about the same timee.
The only safe strategy that have come up with so far is to time the response to "get count of every variant". If the response is over 50ms, then there is a very large selection. But that is rather machine dependent I fear.
0
-
By the way, if one wants to meaure durations, the following handler has significantly more accuracy and resolution than
"get time of current date"
on GetTick_Now()
script GetTick
use framework "Foundation" --> for more precise timing calculations
on Now()
return (current application's NSDate's timeIntervalSinceReferenceDate) as real
end Now
end script
return GetTick's Now()
end GetTick_Now
Adapted from0 -
[quote="NNN636734290044867357" wrote:
Is the site having AppleScript or not ??? I am not able to understand the scripting in the backend.
I suspect these numbers will help if some part of AppleScript or Script Editor is broken, but little help if it’s working but you don’t understand the code.
If you need better understanding, in my experience the best people to ask are the MacScripter forum and the Apple discussions forum.0
Post ist für Kommentare geschlossen.
Kommentare
3 Kommentare