ExternalInterface Slower Than getURL
The test page speaks for itself. Basically, I wanted to see whether it was worth using ExternalInterface for Flash-to-JavaScript communication when the JavaScript function doesn't return anything.
It turns out getURL still has its advantages. My results from this test show the following:
10000 ExternalInterface calls: 1593ms.
10000 getURL calls: 83ms.
That's pretty significant. My theory for the difference in execution speed is that ExternalInterface is waiting for the JavaScript function to finish executing before it allows the next call to take place. With getURL, I believe it is leaving it to the browser to queue up those JS calls, and doesn't bother waiting for a return value.
In my test case, all the JavaScript function does is assign a variable, so it executes pretty quickly. However, in real life, a slow JavaScript function could have your ExternalInterface calls waiting for a return value that never comes.
It turns out getURL still has its advantages. My results from this test show the following:
10000 ExternalInterface calls: 1593ms.
10000 getURL calls: 83ms.
That's pretty significant. My theory for the difference in execution speed is that ExternalInterface is waiting for the JavaScript function to finish executing before it allows the next call to take place. With getURL, I believe it is leaving it to the browser to queue up those JS calls, and doesn't bother waiting for a return value.
In my test case, all the JavaScript function does is assign a variable, so it executes pretty quickly. However, in real life, a slow JavaScript function could have your ExternalInterface calls waiting for a return value that never comes.
posted by tom at 9:43 AM
12 Comments:
Did you test fscommand? Also, you shouldn't rely on EI to callback. Although this is a great feature, you should instead rely on callbacks if possible.
The common use case is to make very few calls anyway, so while the bottlenck may be there, most people wouldn't run into it.
You're one step ahead of me, Jesse. :) I've added fscommand to the tests (view in IE to see the results). FSCommand seems to be a hair slower than getURL, although it has the advantage of not making that clicking noise.
Yeah, most people will not be bothered by the speed difference. However, if you need to be backward-compatible with older players, I'd say it's not worth creating a special build for modern players just to provide ExternalInterface support, as it will not give you a performance increase.
Did you test that in IE? And did you make sure all the getURL calls worked? AFAIK, IE doesn't queue getURL calls and ignores them if they are sent too quickly.
I was able to verify that all the calls completed in Firefox (just wait 5 seconds and an alert should appear with the total number of calls actually completed). For some reason the alert doesn't work in IE (don't have time to figure it out right now), but IE's times are in line with Firefox.
For what it's worth, it might be useful to do benchmarks across various browser brands, versions, and platforms. Part of the communication is handled in the Adobe Flash Player, but the other part is handled in the hosting browser, and these do definitely vary in all types of implementation details.
(The "getURL:js" approach is an oldtime hack, which is nowadays pretty standard in its main support, but which has varied greatly in past browsers, sometimes turning on and off across consecutive browser versions. The FSCommand and externalInterface work uses one API in the Player to talk to various generations of different browser communication APIs... some of the talk on the Mozilla boards does discuss the heavy hit of current implementations.)
I was surprised awhile ago when Brad Neuberg of Dojo wanted to use these browser intercommunication APIs to pass very large amounts of data for storage... do you see usercases where you need very fast repetitive messaging as well?
"do you see usercases where you need very fast repetitive messaging as well?"
There seems to be a push currently to marry Ajax and Flash, and under that architecture I could see a variety of circumstances where performance could become an issue.
In my particular case, I'm creating a SIFR-like SWF Headings library, where mulitple SWFs have to send font metrics to JavaScript for purposes of text reflow. Since the text flow occurs in real time, and I don't want to bog down the browser, the Flash to JavaScript communication has to be highly tuned.
This kind of stuff falls under the category of "things one wouldn't need to do in an ideal world", and I'm sure ExternalInterface wasn't really intended for these extremes. 10000 sequential calls is well beyond what I would ever encounter in real life, but it's a useful benchmark because it illustrates the difference between the two types of calls. If I were creating a Flash 8-only app, I wouldn't think twice about using ExternalInterface. The question for me was really "do I create a separate version for Player 8 in order to take advantage of ExternalInterface" and it turned out there was nothing to gain in my case.
I agree with anomymous : IE overwrites consecutive getURL calls with one another. Having used it extensively in FP7, I had to rewrite code so that consecutive calls in the same flow were replaced by a single getURL with all the JS function calls separated with semi colons. You could be surprised by what would read your alert were it to show... Even the fact it doesn't show should warn you...
On the opposite side, when you say "If I were creating a Flash 8-only app, I wouldn't think twice about using ExternalInterface", I urge you to be more careful, depending on what your app does. Having tried ExternalInterface for an FP8 app, I had to step back to getURL in several occasions : for example when you call JS from flash and it results in the flash object being hidden, then when you display it again, ExternalInterface appears to be dead... And with the brand new FP9, I have even some more strange things related to ExternalInterface.
So, as a conclusion, the choice between the 2 solutions is not only a matter of performance but also of code readability and functionality needed in the flash/javascript integration.
That's correct, getURL calls do not queue properly in IE. I use FSCommand for IE instead, if I need multiple calls.
Even though ExternalInterface is occasionally problematic, I still would not shy away from it. I believe it's going to be around for quite some time, and so it's worth it to learn the caveats and workarounds.
牙醫,植牙,假牙|矯正|牙周病,牙醫診所、植牙,紋身,刺青,創業,批發,TATTOO,皮膚科,痘痘,雷射、脈衝光、除斑,中醫,腫瘤,腎臟病,僵直性脊椎炎,飛梭雷射,肉毒桿菌,玻尿酸,痘痘,脈衝光,醫美,毛孔粗大,醫學美容,seo,關鍵字行銷,關鍵字、自然排序,網路行銷,關鍵字、自然排序,關鍵字行銷、seo,關鍵字廣告,網路行銷,seo,關鍵字行銷,關鍵字廣告,關鍵字,自然排序,部落格行銷,網路行銷,網路爆紅,牛舌餅，婚紗，台中婚紗。
ralph lauren poloburberry polo shirtthe north face jacketcolumbia jacketspyder jacketed hardy clothing ed hardy clothesed hardy shirts ed hardy t-shirts ed hardy sunglasses ed hardy mensed hardy womens Wholesale HandbagsCheap HandbagsWomens HandbagsCheap PursesDesigner HandbagsTennis RacquetTennis Racket
cheap tennis racquet
tennis racquet discount
cheap tennis racket
discount Tennis Rackethead junior tennis racketwilson tennis racquet
wilson tennis racket
head tennis racketbabolat tennis racket
In a womens clothing boutique store, several girls were trying on fashionable new polos men poloswomen polos. In addition to flower dresspolo fashionembroodered polostennis racketsclothing poloclothingedhardyshirtedhardyclothingedhardysummer ed hardy clothingcheap shirtsed hardy brandcheap ed hardypolo shirts cheapcheap tennis racketsdiscount tennis racketsralphlaurenpoloshirtscheappolospolo fashion, flower shirt, flower jacket, even with the scarf pattern is all kinds of flowers.
This comment has been removed by the author.
Post a Comment
<< Home