Re: Play Playlist in iTunes
Re: Play Playlist in iTunes
- Subject: Re: Play Playlist in iTunes
- From: "Mr. Gecko" <email@hidden>
- Date: Sat, 4 Oct 2008 09:07:48 -0500
Ok thanks for the tips
I ran the time test on my play playlist function and it was time =
-0.005 sec which is more than fast enough for me. especially when my
computer is 733Mhz.
On Oct 4, 2008, at 4:26 AM, has wrote:
On 4 Oct 2008, at 03:54, Mr. Gecko wrote:
I am not using AppleScript to do this, I am using AppleEvents, as
you can see in code below.
Aware of that. You'll often find that folks use the name
"AppleScript" as a catch-all term for anything relating to Apple
event IPC. It's easy to lapse into the habit; apologies if it caused
any confusion.
Anyway, regardless of whether you use AppleScript or C to build and
send events, the underlying RPC+query semantics are the same as
they're defined by the Apple Event Manager and by the event handling
code in scriptable applications. The AppleScript language sticks a
thin layer of syntactic sugar [1] over the existing Apple Event
Manager API in order to make it easier to use, but the way it
behaves is virtually [2] identical.
This is way faster than using AppleScript.
It's the extra overhead of calling into the AS component that slows
things down, particularly if you're compiling from source each time.
There shouldn't actually be much speed difference between
AppleScript and other APIs where building and sending events is
concerned; it's the one area where AppleScript's performance is
about as good as it can be. AS, appscript and SB all seem to be
about equal here; the Carbon C API might be a little faster as it's
closest to the metal, but I doubt the difference is significant by
the time you've packed your Cocoa values into AEDescs and back.
BTW, regardless of what API you use, you can also speed up or slow
things down massively depending on the number of Apple events you
use to perform a given task. This can be particularly noticeable
with iTunes, since playlists can often run into thousands of tracks.
Apple event IPC traditionally optimises for fewer, more complex
events over many simple ones, so each event you send is relatively
expensive but, depending on the application, you can often perform
multiple operations in a single event. For example:
#import <Foundation/Foundation.h>
#import "ITGlue/ITGlue.h"
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
ITApplication *itunes = [ITApplication applicationWithBundleID:
@"com.apple.itunes"];
// This sends 3 Apple events:
NSDate *time1 = [NSDate date];
ITReference *tracksRef = [[[itunes playlists] byName: @"stress
test"] tracks];
NSArray *names = [[tracksRef name] getList];
NSArray *albums = [[tracksRef album] getList];
NSArray *artists = [[tracksRef artist] getList];
printf("time 1 = %.3f sec\n", -[time1 timeIntervalSinceNow]);
// This sends N * 3 + 1 Apple events (where N is the number of
tracks in the playlist):
NSDate *time2 = [NSDate date];
NSArray *tracksList = [[[[itunes playlists] byName: @"stress test"]
tracks] getList];
NSEnumerator *iterator = [tracksList objectEnumerator];
ITReference *track;
while (track = [iterator nextObject]) {
NSString *name = [[track name] getItem];
NSString *artist = [[track artist] getItem];
NSString *album = [[track album] getItem];
}
printf("time 2 = %.3f sec\n", -[time2 timeIntervalSinceNow]);
[pool drain];
return 0;
}
gives the following times for a 4000-track playlist:
time 1 = 0.137 sec
time 2 = 5.779 sec
and for a 40,000-track playlist:
time 1 = 2.116 sec
time 2 = 82.634 sec
I'm not sure which approach EyeTunes uses, but it's something to
bear in mind if performance is an issue for you.
I would prefer using AppleEvents because it is the right way to
communicate with different things in the os, using cocoa.
It's all Apple events under the hood. Some APIs just make them
easier to work with than others.
HTH
has
[1] Plus a few magical behaviours such as 'implicit gets' which do
unfortunately muddy comprehension a bit. But I won't claim that
AppleScript is a perfect pedagogical tool, just a convenient one.
[2] See [1].
--
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