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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
