- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Thu, 10 Feb 2011 21:23:26 +0100
* Kyle Simpson wrote: >For the purposes of this discussion, we are combining (but safely so, I >believe) "execution" and "parsing", and saying that we want to be able to >defer the "parse/execution" phase of script loading. The reason it's >necessary to draw the distinction (and point out that parsing is the costly >bit) is to defuse the argument that the script author can simply change the >script to not execute itself until manually invoked at a later time. There are multiple phases between receiving bytes on the wire and having executed the code they represent. Parsing would seem unlikely to be the main problem here (parsing is mainly checking for syntax errors while or after removing the character encoding from the bytes received), while it is quite likely that browsers don't have very fast parsers, without very good benchmarks I would rather suspect the problem is more in finding out about the side effects of the code and eagerly pre-processing code like turning it into machine code and the things that entails like gc runs. There would seem to be no reason why a lazier evaluation strategy would be an appreciable performance hit. You would couple those mainly because decoupling them in implementations so you actually gain much is hard. Anyway, I don't really see the problem with rewriting your code so you have more control over when execution takes place, for instance, you can just do `function load() { eval("...") }` and similar mechanisms. That would in fact seem wiser as browsers would have a better chance to spe- culatively pre-parse the constant you want evaluated than doing that for some code that has been commented out. That would of course require you to change code, and related mechanisms would have other downsides, like they would not degrade as gracefully or not work across origins in all browsers, and so on. You might even make the argument that the proposal here seems like a cheap enough hack that might get traction quickly. On the other hand, dynamically loading code by fiddling script elements into documents is rather ... inelegant. A more viable long term solution would be a proper native script loading programming interface. But it's only been 15 years since people pointed out that's necessary, let's not be hasty when it comes to essential low-level features. -- Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de 25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
Received on Thursday, 10 February 2011 12:23:26 UTC