On Mon, Jul 25, 2011 at 11:16 PM, BGB <cr88...@gmail.com> wrote: > well, there are pros and cons. > > pros: > more compact; > better at hiding ones' source code (decompilers are necessary); > can be executed directly if using an interpreter (no parser/... needed); > ... >
Counters: * We can minify source, or zip it. There are tools that do this for JavaScript. * Hiding code is usually a bad thing. A pretense of security is always a bad thing. But, if someone were to insist on an equal capability, I'd point them at an 'obfuscator' (such as http://javascriptobfuscator.com/default.aspx). A tool dedicated to befuddling your users will do a much better job in this role than a simple bytecode compiler. * we rarely execute bytecode directly; there is a lot of non-trivial setup for linking and making sure we call the right codes. Besides, the real performance benefits come from compiling the code - even bytecode is typically JIT'd. Higher-level source can allow more effective optimizations, especially across library boundaries. We'll want to cache and reuse the compiled code, in a format suitable for immediate execution. JavaScript did a poor job here due to its lack of a module system (to prevent name shadowing and such), but they're fixing that for ES.next. > > the main merit of a bytecode format is that it could shorten the path in > getting to native code, potentially allowing it to be faster. > Well, it is true that one might save a few cycles for a straightforward conversion. The use of a private IL by a compiler isn't the same. You aren't forced to stabilize a private IL the way you need to stabilize the JVM ops. Regards, Dave
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
