Yes. HTTPService is great! It's worlds better than Socket. Easy as pi, and it works async...
I don't think ActionScript offers better performance per se (it's probably slightly worse). It probably depends on what your performance bottleneck is. If it's interacting with the app, ES is probably faster. If you have a lot of sorting for example, ActionScript probably has a strong advantage (since that kind of processing is done at a much lower level using better algorithms...)
To clarify a couple of points...
You should be looking at Creative Suite Extension Builder and the CreativeSuite 5 SDK. PatchPanel was a Labs project, and is no longer supported.
ActionScript is a single threaded environment. You can (and should!) take advantage of it's strong event support to handle async operations; but, you can't have a truly background operation (as with a separate thread).
Take the following:
public class AsyncDemoInDesign
public static function run():void
var app:Application = InDesign.app;
var timer: Timer = new Timer( 10, 1 );
timer.addEventListener(TimerEvent.TIMER, timerHandler );
trace( "Timer Started" );
public static function timerHandler( ev: TimerEvent ): void
trace( "The timer handler executed" );
public static function longRunningFunction(): void
trace( "long process started" );
var i: int = 0;
var s: String = "a";
while ( i++ < 5000000 )
s += "a";
trace( "long process done" );
When executed the trace will be:
long process started
<a couple of seconds elapses here>
long process done
The timer handler executed
So even though you set the timer to fire 10 ms after the "start()" method is called, the event does not actually fire until the current process stops. Furthermore, InDesign is blocked until execution completes.
On performance, we ran sets of tests, the performance interacting with the host application is comparable with ExtendScript. If you're sending large amounts of data to a host app (say a large block of text - like 500K-1M), the ActionScript interface is actually faster. As for general execution of ActionScript (not interacting with the host application), it's significantly faster than ExtendScript.
Very interesting to hear about the performance tests.
What kinds of tests did you do to compare ActionScript performance to ES performance? What areas had the most dramatic improvements?
I'm not surprised that pure AS performance is better than ES. An awful lot of work has gone into optimizing the Flash and AIR runtimes, and I'm sure we're benefiting from that...
thank you very much for your post.
I actually meant CS5 SDK ... dunno why i wrote PatchPanel. :-) In regard to Extension Builder: I cannot find further information about to download it (or even a demo). Can you tell me where I can find it?
Okay, I'd like to take advantage of AS's strong event support, but how do they offer an alternative to async/background-tasks? For example I have an external application that prepares some data for InDesign. After the preparation is done I want to trigger a certain action in the Adobe-Scripting ecosystem. But without having to block InDesign all the time until the external preparation is done.
Thanks for sharing these performance insights. It's enough for me to decide if I should switch to switch to CS5 SDK (=ActionScript) for future automations/scripts.
If you want truly async processing, you can probably use NativeProcess to launch an external process (in an AIR or native app), and use a timer to moniter when it's done...
Thanks for your reply. However, although this might work, it will still block the whole host application until the execution stops (the timer clears its interval after the external Process exited and thus the script finishes).
But wait a minute ... when it is possible for a "true" extension (using the C++ interfaces) to start external processes that work async, I could write a super minimalistic one (don't speak C++) that exposes some functionality where scripts could register themselves (before they immediately exit) to be re-called (with some args like process' exit code, timestamps, asf.) once a specific process exited.
However, although this might work, it will still block the whole host application until the execution stops...
No it won't. (If you do it the way I intended.)
An external NativeProcess is async. Once NativeProcess is launched, you free up the app. I didn't intend to get a return value on the NativeProcess. Just write a text file with the NativeProcess (or something) and check for its existence with a timer event. Simple, and it should be very effective...
The tests I ran were against InDesign.
I created two identical tests that created documents, added frames to those documents, places images, set content text, removed frames, etc. One of them was written in AS, the other ES. I didn't include any of the really fancy stuff ID can do, just the basics. Then I ran them multiple times, creating thousands of documents, zillions of frames, etc. I also set text contents at various sizes up to 1MB.
The results were such that, for simple stuff and "normal" sized data transfers, AS and ES were virtually identical. When the amount of data increased, AS had a clear advantage.
As for raw performance of AS and ES (host app calls not involved), take the example above with the 5,000,000 iterations (and string copy's), AS handles it in just under 2 seconds (averaged 1996 ms here). By contrast, the same code, but only 500,000 iterations took 101 seconds. Granted, not really a significant test, but illustrative none the less.
ActionScript certainly allows async code. Just not a separate or background thread. You can call a web service that takes minutes to reply, ID will not be blocked while waiting for the reply (so long as the code that executed the web service call has exited). Once the web service reply is received, the event will fire, and your handler would do something with the data.
The example I gave above was to demonstrate that if I execute something that is async (such as the timer), but keep AS busy (by doing some processing for about 2 seconds), the timer event, even though it was set to fire in 10ms, will not fire until my original process (the "run" method) completes. The event fires immediately after it stops. Your original question made me think you were looking for a background thread, which AS does not have. But this does not mean that you can't do significant async code.
Wow! 500 times faster? That's a serious difference on the raw data!
I have a long script I wrote for a client where at least 90% of the processing time is spent sorting data. It would be very interesting to convert that script to AS and compare the results. A nice job for when I have time (i.e. definitely not in the near future...) I'd say sorting will probably be an enormous difference in performance, because ActionScript uses a version of quicksort (as opposed to ES's bubblesort), and it's done on a very low level (as opposed to the very high level of ES)...