Compartilhar via

Compatibility vs. Performance

  • Artigo

Earlier
I mentioned that two of the design goals for JScript .NET were high
performance and compatibility
with JScript Classic"urn:schemas-microsoft-com:office:office" />.
Unfortunately these are somewhat contradictory goals! JScript Classic has many dynamic
features which make generation of efficient code difficult. Many of these features
are rarely used in real-world programs. Others are programming idioms which make programs
hard to follow, difficult to debug and slow.

JScript
.NET therefore has two modes: compatibility
mode and fast
mode. In compatibility mode there should be almost no JScript
program which is not a legal JScript .NET program. Fast mode restricts the use of
certain seldom-used features and thereby produces faster programs.

The
JSC.EXE command-line compiler and ASP.NET both use fast mode by default. To turn fast
mode off in JSC use the /fast- switch.

Fast
mode puts the following restrictions on JScript .NET programs:

* All
variables must be declared with the var keyword. As
I discussed earlier, in JScript Classic it is sometimes legal to use a variable without
declaring it. In those situations, the JScript Classic engine automatically creates
a new global variable but when in fast mode, JScript .NET does not. This is a good
thing -- not only is the code faster but the compiler can now catch spelling errors
in variable names.

* Functions
may not be redefined. In JScript Classic it is legal to have two or more identical
function definitions which do different things. Only the last definition
is actually used. This is not legal in JScript .NET in fast mode. This is also goodness,
as it eliminates a source of confusion and bugs.

* Built-in
objects are entirely read-only. In JScript Classic it is legal to add, modify
and (if you are perverse), delete some properties on the Math object,
the String prototype
and the other built-in objects.

* Attempting
to write to read-only properties now produces errors. In JScript Classic writing
to a read-only property fails silently, in keeping with the design principle I discussed
earlier: muddle on through.

* Functions
no longer have an arguments property. The
primary use of the arguments property
is to create functions which take a variable number of arguments. JScript .NET has
a specific syntax for creating such a function. This makes the arguments object
unnecessary. To create a JScript .NET function which takes any number of arguments
the syntax is:

function
MyFunction(... args : Object[] )

{

  //
now use args.length, args[0], etc.

}

Generally
speaking, unclear
code is slow code. If the compiler is unable to generate good
code it is usually because the restrictions on the objects described in the code are
so loose as to make optimization impossible. These few restrictions not only let JScript
.NET generate faster code, they also enforce good programming style without overly
damaging the "scripty" nature of the language. And if you must run code which has
undeclared variables, redefined functions, modified built-in objects or reflection
on the function arguments, then there is always compatibility mode to fall back upon.

JScript
.NET also provides warnings when programming idioms could potentially produce slow
code. For example, recall my earlier article on string concatenation. Using
the += operator
on strings now produces a warning which suggests using a StringBuilder instead.
JScript .NET also produces warnings when code is likely to be incorrect. For example,
using a variable before initializing it produces a warning. So
does branching out of a finally block
now produce warnings, and so on.

Comments

  • Anonymous
    October 24, 2003
  • Built-in objects are entirely read-only. In JScript Classic it is legal to add, modify and (if you are perverse), delete some properties on the Math object, the String prototype and the other built-in objects. Glad you didn't call this "goodness". My host adds a few dozen string functions for ease of use (justify, space, repeat). I see being able to expand the built-in library as a strength of ECMAScript. It also overwrites Function.prototype.toString ;-) Sure would be nice if it were possible to enable a "mode" to add to these built-in objects, yet still get the benefits of complation.
  • Anonymous
    October 24, 2003
    Disclaimer: I'm very much of a JavaScript/ECMAScript aficionado. If you want to see the extent, check out http://w3future.com/html/beyondJS/ to see the BeyondJS library developed by Sjoerd Visscher and myself.When I first heard of JScript.NET I was ecstatic - here was the chance for JavaScript to make it into the big-leagues. Becoming a full-blown member of the .NET environment would allow JavaScript to go beyond browser scripting into the field of real, main-stream application development.After playing a bit with JScript.NET I have to admit I became disappointed. It seems to me that in order to play in the .NET field and provide an acceptable level of performance, JScript.NET abandons many of the features that make JavaScript such a cool and unique language. Instead it becomes something of a C# clone. Put another way: given that C# is the main language of .NET, I can't see any major reasons to pick JScript.NET over C# (and apparently I'm not the only one: http://blogs.gotdotnet.com/EricLi/commentview.aspx/cd88c241-27f4-410c-b3a4-716cae1b63db why did they choose C# and not JScript.NET?)With regards to Eric's points specifically:1. I wholeheartedly approve of enforced var use. The only addition I would ask for is type inference not only for performance but also for verifying correctness, ML-style.2. This is what makes functional programming in JavaScript possible. I'm guessing you also got rid of unnamed functions (lambdas) and closures.3. The JavaScript model of object as directory is one of the cool things about it that makes it so unique. And the ability to modify the behavior of builtin objects is also an extremely powerful feature (it is what makes BeyondJS possible).By getting rid of prototypes and adding classes, JScript.NET becomes just another C++/Java/C# clone, instead of a unique and viable choice.4. A good thing5. But what about the caller and callee properties?To see more comments I've had about JScript.NET check out: http://www.google.com/custom?sitesearch=lambda.weblogs.com&q=jscript.net+shappirPlease note that my intent is not to disparage either .NET or JScript.NET. They are both great technical achievements. My point is simple: the same changes meant to enhance JScript also robed it of its reason for being.
  • Anonymous
    October 24, 2003
    The comment has been removed
  • Anonymous
    October 25, 2003
    The comment has been removed
  • Anonymous
    October 25, 2003
    > So, in fast mode, am I allowed to write:Absolutely, yes.> Also, can I use a function reference (object) as a delegate?JScript .NET can coerce a function reference to an existing CLR delegate type, but provides no syntax for declaring new CLR delegate types. Unfortunately we did not have time to get that feature in.The rest of your points I'll follow up on privately.
  • Anonymous
    October 29, 2003
    Eric:I'd be interested in hearing about the rest of your points too.One of the reasons I like JavaScript is its "prototype" programming paradigm based on some ideas pioneered in the "Self" language/system.IMHO, it appears that JScript.NET is moving (has moved) away from those roots.Personally, I would have enjoyed seeing more "Self-isms"... perhaps allowing one to provide runtime prototyping in a live system, rather than a move to static compilation and static type checking. On the other hand, this would likely be at odds with generating efficient .NET code... the JIT compiler for Self was/is a lot more sophisticated than the one (I am sure) the .NET VM has.
  • Anonymous
    January 23, 2006
    This is somewhat off the point of this thread but generally related. I do considerable programming in Javascript/Jscript in the form of DHTML applications using .HTAs. I won't go into detail about why but having application like functionality while maintaining script compatibility with IE is one good reason. In other forums (www.dotnet247.com) someone was talking about the possibility (likelihood?) that Jscript.NET might be made clientside. I refer to this message [Hi, There are no concrete plans for this at the moment but that could change. We are looking for customer feedback on this (there is very little so far).
    Embedding JScript .NET inside the browser is definitely a "cool" thing to do, but unless customers come back and say "Hey, this would really make my life easy!" or "This enables a whole bunch of new scenarios for me" it's
    probably not going to happen. -- Peter Torr ]
    Peter speaks as if he works for Microsoft. My question... Might you embed Jscript.NET in IE7? If you need scenarios as to why this would be worthwhile I can supply a few concrete ones. In general I'd like to stimulate conversation on this topic, perhaps on its own thread.

    Thomas Giebink
  • Anonymous
    January 23, 2006
    Peter was the program manager for JScript .NET.

    I would personally love to see JS.NET in IE7 but I know of no plans to make it happen. Feel free to post any ideas you might have and I'll pass them on to the people who presently own script.
  • Anonymous
    May 01, 2008
    PingBack from http://performance.survol.fr/2008/05/un-mode-fast/