Blog

AutoRate in Objective-C

I’m currently re-doing AutoRate in Objective-C. I’ve heard from a few users with very large libraries (20,000+) that the current version takes several hours to go through their entire library. Should be able to do much better than that in Obj-C instead of AppleScript.
Should give me more scope to do some other things as well, as I’m more comfortable with Obj-C than AppleScript. One feature I’m considering is live updating of ratings – AutoRate runs in the background and watches tracks that are played. That will yield the ability to form more accurate ratings, instead of having to use a couple of heuristics to ‘guess’.
So, stay tuned.

Related posts

Tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

4 Comments

  1. Posted July 7, 2007 at 5:11 am | Permalink

    Regarding using ObjC in place of AppleScript, check out objc-appscript if you haven’t already done so:

    http://appscript.sourceforge.net/objc-appscript.html
    

    However, don’t expect a straight translation from AS to ObjC to automatically provide vast performance improvements. While the AppleScript language certainly has its share of performance problems, Apple event IPC has various bottlenecks of its own which you need to be aware of.

    Basically, there are two problems dealing with large data sets in AppleScript:

    1. The first is that iterating over AS lists normally has O(n*n) efficiency, although there are known kludges you can use to get it down to O(n).

    Alternatively, switching to another language (Python, Ruby, ObjC, etc.) lets you avoid that problem entirely.

    1. The second is the overheads associated with Apple event IPC. While sending interprocess events is much more efficient than in pre-OS X days, it’s still slow compared to local procedure calls. It can also take a non-trivial amount of time for the target process to resolve object specifiers and perform commands.

    Switching languages won’t help you here; your only option is to minimise the number of events you send wherever possible, e.g. sending a few more complex events:

    tracks_ref = app('iTunes').playlists[1].tracks
    names = tracks_ref.name.get
    artists = tracks_ref.artist.get
    albums = tracks_ref.album.get
    names.zip(artists, albums).each do |name, artist, album| 
        # do stuff here
    end
    

    is far, far more efficient than sending many simpler ones:

    track_list = app('iTunes').playlists[1].tracks.get
    track_list.each do |track|
        name = track.name.get
        artist = track.artist.get
        album = track.album.get
        # do stuff here
    end
    

    There are some notes about performance optimisation in the appscript documentation, and I think Matt Neuburg also discusses these issues in his AppleScript book.

    HTH

    has

    http://appscript.sourceforge.net http://rb-appscript.rubyforge.org

  2. Mike
    Posted July 7, 2007 at 7:49 am | Permalink

    Thanks for the great tips! I’ll check those things out – it’d be nice to reduce the bottleneck that is AS as much as possible.

  3. Mike
    Posted July 7, 2007 at 9:14 am | Permalink

    This is great – Appscript is going to save so much time. I’m glad you mentioned it!

  4. Bjorn
    Posted August 22, 2007 at 6:09 pm | Permalink

    Great stuff! I say thnx and looking forward of the next release.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use Markdown (surround code in `back-ticks`), or these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

Subscribe without commenting