Jump to content
IGNORED

AppleScript performance


Recommended Posts

Recently, I've been sorting thru my library, picking what to keep on my notebook from a larger collection. Anytime I manage music, I have quite a few AppleScripts for various tasks, the most complicated exporting to and updating metadata such as rating, play count, last played date, (edited) track name & artist(s) to and from MySQL, so I can delete and re-add while keeping all that. I'm curious about performance : some scripts such as fixing classical tags (a bunch of search and replaces such as "No. " w/ "No." to make easier search, or "C Sharp" w/"C-Sharp" seem to run at not a bad speed, though adding a new tag such as comment or total disc, and the execution time is significantly longer. I don't think selection method (such as fixed indexing [not quite sure what that does]) has much of an impact, and perhaps there isn't much that can be done, but I am curious why speed isn't better. I can modify tags thru Get Info, that runs quite fast, yet scripting isn't so great. Maybe what remains is for Apple to improve what seems to have not changed much in years.

Link to comment

AppleScript performance in iTunes is dependent on many factors, including the number of track entries and playlists in the library, how long it takes an AppleScript to do any computations, whether or not a script is a compiled script or application, whether a change obliges iTunes to perform any housekeeping, and so on.

 

Fixed indexing set to true keeps the indexing to Play Order; no matter how a playlist is sorted, the first track in its Play Order is always the same track, the second is always the same track, and so on. Set to false, indexing is based on the current sort order, so the first track is always 1, the second track is always 2, and so on. I think of it a "free indexing" as opposed to fixed indexing.

 

Try this script on a small playlist with fixed indexing set to true. Then set it to false and change the sort order of the playlist. You'll see the various tracks selected according to how fixed indexing is set.

 

tell application "iTunes"

set fixed indexing to true

repeat with i from 1 to count tracks of view of front window

reveal track i of view of front window

end repeat

end tell

Link to comment

Thank you Doug. That is quite quite helpful. I had a sense fixed indexing might be something like that but didn't try or test it out.

 

Factors influencing performance is very insightful. I had about 20 smart playlists, perhaps the only kind that affects speed ; I've reduced to 12 as well as simplified conditions. As a test, I created an empty library, removed default smart playlists, and script performance is fairly decent. Still not as fast as setting metadata thru Get Info but not too bad at all. With my main library, now improved a bit.

 

Have about 20,000 tracks and 10,000 audiobook tracks in iTunes. I resubscribed to Match yesterday ; that is causing other problems like setting metadata thru get info or scripts, or deleting tracks, somewhat intermittently not working, and needing an iTunes relaunch or a few. That's causing some headaches for the scripts I use for new imports.

 

New music is Apple Lossless ripped with XLD. I'm not sure if there's a small impact like if perhaps ID3 version is different and iTunes is changing that, or if any tag restructuring is done at first mod. Am quite curious about more details of performance but testing might be too much effort at the moment, and I'm not sure if any books cover that.

 

One script that I use to set comment from the clipboard, checking each track is part of the same album as first in selection :

 

repeat with theTrack in sel
                   if album of theTrack is equal to albumName then
                       if comment of theTrack is equal to "" then
                           try
                               set comment of theTrack to newComment
                           end try
                       end if
                   end if
               end repeat

 

35 tracks - 5 seconds. The try blocks I'm using more to avoid error dialogs that I'm getting when setting metadata fails (not sure if that's due to current iTunes in combo w/10.11.2 beta). Not bad but surely I wish it were better. For the same number of tracks, another script that updates from mysql, when no metadata is changed except for setting a default rating of 2 stars, 9 seconds. That is perhaps what takes the longest. It's been a while since I've looked at it, it more or less works well, though I might eventually go thru and see if I can improve it. This is what it looks like, if you're curious or perhaps you'd find it useful :

 

http://pastebin.com/ecbkrRTh

 

You're certainly more skilled at scripting than I ; if it weren't much effort, a quick look and suggestions, certainly not requested, would be much appreciated.

Link to comment
A script will never be as fast as the native app. This is an unrealistic goal.

 

I think you'd want to see any errors, so you know how to accommodate the problems.

 

True, though it wasn't a goal and I haven't thought about saving as an applescript app to see if that'd make a difference. I was thinking that perhaps when running applescript, additional logic is done by iTunes that might also change speed. Improvements of speed I was looking for were merely changes to setup, such as less playlists as you hinted, or script changes.

 

Hiding errors is ok for now. I use growl/notification center logging when writing or moding scripts ; the hiding of errors thru try is mainly to work around current iTunes bugs like file auth errors (from what I remember) when setting metadata on a series of tracks where most will be ok, then it'll fail on one. Since I re-started setting track names & artists from iTunes store data, I use your script Import Track Data From Text Files, modded to use a certain text file and playlist so it doesn't prompt at run ; no script probs yet all of a sudden, trying to set a field will sometimes fail, and I need to rerun the script sometimes several times before all tracks are set.

Link to comment

I decided I wanted to rename a box set of 100+ cds, for each individual vol, "Vol.x" instead of "Vol. x". Currently running on ~1300 tracks (rename album would be easier, though haven't tried that in script). Speed seems ok so far, perhaps since I removed some smart play lists. What I had hinted at in the beginning of one factor affecting performance, but did not say since I think it is true, and those that use applescript enough are possibly aware, is that it's not necessarily applescript speed, but what happens the moment a tag is modified, and iTunes has a delay doing something before script execution continues. It's iTunes speed at processing commands that could possibly be much better.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...