I'm struggling with a very nasty performance issue. It appears to be due to calls (from javascript) to methods exposed through the ExternalInterface.addCallback ActionScript method. Well, numerous calls (exactly 888 calls). The "boundary crossing" (from js to as) seem to be responsible (and not my code, which I first suspected).
The measures sure ain't exact (or even reliable to the second - though they do measure just the boundary crossing), but either way, between IE6 and IE8, there is a shameless x20 factor. Compared to Firefox, that's up to a x100 factor.
I just can't believe Microsoft boosted their JScript engine in such drastic proportions. Or should I?
My guess is rather that the addCallback mechanism (and associated javascript glue - __flash__argumentsToXML, __flash__addCallback and the rest of the unfortunately mysterious stuff) is different depending on the IE version.
Anyhow, the only way I can think of right now is ripping out the injection "black magic" and bypass/rewrite parts of it. This here is the most informative I could find yet (for that purpose).
So, if you work at Adobe and have insight about how the player works on that:
- is IE6 treated differently (as far as the addCallback mechanism is concerned)?
- if not, are you aware of serious perf problems with it?
- is there some proper documentation about the whole "magic" javascript methods related to the addCallback bridge, or shall I consider my only way out is reverse-engineer it?
Thanks in advance for any answer!
Comments
#1
dmp
Wednesday, March 3 2010, 19:30
I thought I would had that ripping out the eval in __flash__addCallback doesn't provide any real speed-up. 99% of the time is spent inside __flash__argumentsToXML, with 20% of that inside __flash__escapeXML. Which is good news, because I can rewrite these.
Obviously, I'm bound to the XML format that CallFunction is supposed to eat - I hope there is a way to optimize these serialization methods.
#2
johnvh
Thursday, March 25 2010, 04:22
Ah yes, I've heard of flash<->js performance issues before, and have also mucked around with the "magic" javascript bridge methods. Any luck with feedback from Adobe? Did you end up rewriting the serialization methods successfully?
#3
dmp
Thursday, March 25 2010, 11:58
> Ah yes, I've heard of flash<->js performance issues before, and have also mucked around with the "magic" javascript bridge methods. Any luck with feedback from Adobe? Did you end up rewriting the serialization methods successfully?
No feedback from them - though I haven't really pushed to obtain any, besides this post.
Either way, the whole serialization mechanism is rather heavy (XML + string concatenation is not that hot...), and the culprit clearly is in:
function __flash__escapeXML(s) {return s.replace(/&/g, "&").replace(/</g, "<").replace(/>/g, ">")
.replace(/"/g, """).replace(/'/g, "'");
}
Which can be enhanced (for a significant perf boost) by using a functional callback instead (and forget the single quote replacement- no need for that, actually):
value.replace(/["<>&]/g, function(str) {switch (str) {
case '"' :
return '"e;';
break;
case '&' :
return "&";
break;
case '<' :
return "<";
break;
case '>' :
return ">";
break;
}
return str;
});
If you *really* *really* need to support IE6 as well, and know that the passed arguments are often the same, you can achieve a good perf boost again by caching the escaped strings (as ugly as this sounds).
Either way, I'm working on a new version of JSAS that implements a (way) better js<->as mechanism and drastically reduces the length of data going back and forth over the first version (that wrongly assumed it was efficient :-)) . I think I'll release that sometimes during April.
All in all, I think the authors of ExternalInterface simply never thought people would "abuse" this (like we did) :-).