Re: How to access iTunes using cocoa
Re: How to access iTunes using cocoa
- Subject: Re: How to access iTunes using cocoa
- From: has <email@hidden>
- Date: Tue, 26 Jan 2010 20:45:46 +0000
Jens Alfke wrote:
> On Jan 26, 2010, at 11:13 AM, has wrote:
>
>> The Apple Event Object Model was optimized for System 7, where IPC
>> was extremely expensive
>
> I know; I was on the AppleEvents engineering team at the time :)
>
> IPC is still extremely expensive, by the way, although not quite as
> much so. The actual OS-level process switch is faster, but there is
> still a lot of work involved in marshalling and unmarshalling data.
I think a big hit comes from the time it takes to evaluate Apple event object specifiers. The cost-benefit tradeoff of having a complex, query-driven IPC system is much poorer on OS X, both in terms of performance and ease of implementation (one of the reason so many apps have lousy AE interfaces is because they're so damn hard to implement). The main bottleneck on OS 7-9 was the OS-level messaging system; in OS X, it's evaluating those complicated messages in the target application process. Apple missed an opportunity in not designing Cocoa Scripting to be simple, fast, robust and dumb. (But perhaps that's an opportunity for some third-party developers with good knowledge of server-side Apple events to step in...?)
>> so generally works best if you can use a few complex commands rather
>> than lots of simple commands.
>
> Agreed. The problem is that iTunes doesn't implement the complex
> commands well. A lot of them either fail, or are implemented using
> linear search instead of querying the database.
>
> For example, you can't get properties of multiple items:
> album of every track of every playlist whose artist is "The Beatles"
> fails with error "Handler only handles single objects". Instead you
> have to remove the "album of" part, get back a list of object
> specifiers, and loop over them getting the album names. Which of
> course involves lots of IPC calls.
Or you could factor it so that you get a list of playlist references, then iterate over that. Mind you, all tracks should be in your main library playlist, so you really only should need to query that, which iTunes can manage. (Another iTunes wrinkle to watch for: if a playlist contains no matching tracks, iTunes will return an error rather than an empty list; so be prepared to deal with that.)
> There are other cases of 'whose' queries that take extremely long to
> run, depending on the size of your library, because they do a linear
> search. Try this:
> id of every track whose played count is 1234
> On my 2.4GHz MacBook Pro this takes 15 seconds to run, with iTunes
> consuming 100% CPU. (I do have 10,000 tracks in my library.) By
> comparison, creating a smart playlist in iTunes with the same criteria
> is instantaneous.
Apple have put little apparent effort into maintaining and updating iTunes' AE support over the years. (And iTunes is probably one of Apple's most heavily scripted apps.) So it wouldn't surprise me if the GUI is taking full advantage of the underlying database's capabilities while the AE interface isn't. But that's a rant for the AppleScript list. For your particular example, I would try grabbing all track ids and all played counts, then iterating over them yourself. I've not tried it here, but it might go a bit faster.
But aside from grumbling about Cocoa Scripting, we're getting OT for cocoa-dev. If anyone wants to discuss this stuff further, we should take it to the AppleScript-users list:
http://lists.apple.com/mailman/listinfo/applescript-users
Regards,
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden