Performance of Applescript with C1
Hello.
Since C1 is poor with keyword management, I manage keywords with another app. To at least easily browse them in C1, I have written an application which loads the tree of keywords from all the XMP files and generates a batch Applescript that creates a hierarchy of filter collections, matching the keyword tree. I've been using it with success for a couple of years. It is quite long (today 3.600 collections are created) and it is also quite slow (several hours), but within the threshold for an overnight run, and it was tolerable (furthermore I run it a few times per year). I've had some curiosity on why creating a collection takes so long, but in the end it was not worth investigating too much.
But now the thing has grown up the the point that a night is not enough and I need to optimise it in some way. I've noted that the same script can take a very variable amount of time to run, from 2 to 12 hours (of course with equal system conditions, that is the computer is not running other intensive stuff). For what I've discovered so far, the following conditions speed things up (even though I'm not sure it's deterministic):
- quitting and relaunching C1 before running the script
- not having selected photos in the browser
- not expanding the tree of user collections (I believe the really important thing is not to expand the new tree that is being created)
- in general, not doing anything with C1 before running the script
- having C1 as the focused app (this sounds really strange, but it seems it's like that)
Do you have other ideas, hints? Do you think it makes sense to ask C1 to optimise this?
Thanks.
PS The script is an unrolled loop of iterations such as the one below:
try
set progress text to "Importing: Workflow/workflow:published/workflow:published#twitter-weekly"
tell _workflow_published to make collection with properties {kind:smart album, name:"workflow:published#twitter-weekly", rules:"<?xml version=\"1.0\" encoding=\"UTF-8\"?><MatchOperator Kind=\"AND\"><Condition Enabled=\"YES\"><Key>IB_S_CONTENT_KEYWORDS</Key><Operator>6</Operator><Criterion>workflow:published#twitter-weekly</Criterion></Condition></MatchOperator>"}
set progress completed units to 3670
set ___elapsedtime to (current date) - ___basetime
set ___ct to ___elapsedtime * 0.000272
set ___completionTime to "" & (___ct div 60) & " minutes to complete"
set ___eta to time string of ((current date) + ___ct)
set progress additional text to "3670 / 3671 — 99% " & ___completionTime & " " & ___eta & ""
on error errorMessage number errorNumber
log "errorMessage: " & errorMessage & ", errorNumber: " & errorNumber
log ">>>> keyword: Workflow/workflow:published/workflow:published#twitter-weekly"
end try
-
My experience is limited to running script that copy metadata from Numbers spreadsheet based on part of file name. Speed is dependent mostly on number of images selected. It is really surprising that from certain number of images performance degrades very dramatically. I usually do batches off up to 500 images at a time. There are some optimization tricks, like reusing data or limiting searches. For me it took over 4 years to tune my script so it has decent speed. At the beginning I left it overnight to finish batch of 10000 photos, now it would take it maximum 2-3 hours instead of 12.
0 -
Any enabled filters also impacts performance even when doing them natively inside Capture One. With each operation the filters seem to re-evaluate.
0 -
Would love to understand more about your script.
Are you working with catalog or session?
Do you create the smart album before importing the images?
To programmatically create a smart album takes no time (.04 sec roughly) with no images in the session or catalog.
After the script runs and images are imported are any of the smart albums returning no result? Therefore, are smart album created that aren't required?
Your progress text looks pretty complex if commented out does it run faster?
0 -
I have found that a script speeds up enormously if you can avoid iterating AppleScript commands.
EG “get name of every variant” is much much faster than repeating “get name of variant x” for all x.Its also faster to get object’s ID than any other data, and the ID much better for searching and comparison purposes.
0 -
You may be able to avoid the smart albums altogether by configuring the Filters tool to filter on keywords.
At the top right hand corner of the filters tool are three dots, clicking on these brings up a short menu, one of the menu items is “show/hide filter”. Selecting this item brings up a menu that allows you to select what is included in the Filters tool menu, one of those items is “Keywords”0 -
I find any kind of filters being enabled while updating metadata affects performance dramatically. Every metadata operation while filters are enabled in Capture One feels like it is re-evaluating the browser view based on the filters and updates to the metadata.
0 -
If these keywords are all in the XMP files, are they also in Capture One's keywords? If so the built-in filters too already has hierarchical keywords and you can select them one at a time or multiple ones. No need for smart albums. You also can load a hierarchical keyword vocabulary into the keyword tool and use it to add keywords to images. When I migrated from Apple Aperture and Adobe Lightroom to Capture One I exported their keywords into a tabbed text file. Each level of tab indent represents a new level of nesting in a keyword hierarchy. Keywords with no tabs are root hierarchy keywords.
A text file with this content ...
United States
Maryland
Howard County
Columbia.. would import into the keywords tool as ..
United States > Maryland > Howard County > Columbia
.. and would appear as a collapsible hierarchy in the keywords section of the Filters tool.
We can filter on any level within that hierarchy.
See this blog post on Image Alchemist.
0 -
In my first years of using Capture One, I was quite inconvenienced by slow performance, which I eventually found was due to filters. The last two years I have not been troubled by this, I wasn't sure if I could attribute this to my better computer (Mac Studio M1max with 64GB of RAM) or to an improvement in Capture One. Based on Walters comment it is probably the new Mac.
While I was struggling with Capture One filter speed, I found the following.
1) Capture One seems to evaluate every filter on every operation, even the filters that are not shown. However, this only happens if the tool tab with the Filters tool is active. Consequently I made a custom Tool Tab for the Filters tool, and removed it from the Library Tool Tab. This helped considerably with the speed, and it also gives more space to the Library tool and the Filters tool.
2) It's best to avoid putting text content in fields meant for dates. I think my original slowdown problem was worsened due to this. My best guess: When Capture One has to update the filters tool, it effectively has to do a sort on every metadata field (to get the count of each value). The date fields seem to be optimised for dates. If the field contents are only dates each date can be represnted by a number, the best sort is different than for filelds with text contents. One variant with text which is not a date changes the sort.
0 -
Using currentdate to measure the duration in Applescript suffers from poor resolution. There is a better way using the the following handlers, which I have adapted slighty from the original post in MacScripter
Usage
set MarkA to GetTick_Now()## Your code here
set MarkB to GetTick_Now()
set theDuration to MSduration(MarkA, MarkB)Handlers
on MSduration(firstTicks, lastTicks)
# Result is duration in milliseonds
# From MacScripter Author "Jean.O.matiC"
# Modified to eliminate "round to nearest" but similar result and faster
# inputs are durations, in seconds, from GetTick's Now()
return (get (10000 * (lastTicks - firstTicks)) as integer) / 10.0
end MSduration
on GetTick_Now()
# From MacScripter Author "Jean.O.matiC"
# returns duration in seconds since since 00:00 January 2nd, 2000 GMT, calculated using computer ticks
script GetTick
property parent : a reference to current application
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_Now0 -
Hi Eric,
I use a similar handler but don't use it within a script call which I've found to adds back in Applescripts inaccuracies. Adapting yours below.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
set MarkA to GetTick_Now() ## Your code here
set MarkB to GetTick_Now()
set theDuration to MSduration(MarkA, MarkB)
on MSduration(firstTicks, lastTicks)
# Result is duration in milliseonds
# From MacScripter Author "Jean.O.matiC"
# Modified to eliminate "round to nearest" but similar result and faster
# inputs are durations, in seconds, from GetTick's Now()
return (get (10000 * (lastTicks - firstTicks)) as integer) / 10.0
end MSduration
on GetTick_Now()
# From MacScripter Author "Jean.O.matiC"
# returns duration in seconds since since 00:00 January 2nd, 2000 GMT, calculated using computer ticks
return (current application's NSDate's timeIntervalSinceReferenceDate) as real
end GetTick_Now0 -
Good Call Rick. I have these handlers, and others, in a "do nothing" "Utilities" script in my Script Library. Putting the code in a script allows me to put the 'use framework "Foundation"' in the handler, instead of having to remember to put the Use statement at the beginning of every script thta uses this handler.
Perhaps I should just put 'use framework "Foundation"' at the beginning of every script, regardless. I might also try putting putting 'use framework "Foundation"' at the beginning of my "Utilities" Script.
0 -
Yeah I have Script Debugger add it to the start of each script I use a ton on ASobj-C so need it for pretty much everything.
Hopfully Fabrizio replies I'm intrigued by his workflow.
0
Post is closed for comments.
Comments
12 comments