5 ms·

Same results: http://jsperf.com/dart-hello-world-test-with-optimize/2 http://jsperf.com/dart-hello-world-test-with-optimize/2

cdata 15y ago
Let's be realistic with ourselves here: is all that overhead ever going to compete with ten lines of "low level" (ha..) JavaScript? No. The problem here, and what is making us chuckle so much, is that the project as presented to us is not magical. For whatever reason, some of the brightest minds in our industry have not presented us (at this time) with a cross-compiler that is both robust enough to support large apps, and intelligent enough to self-optimize its output. Were we expecting a JavaScript killer from Google? Some of us were, with cynical apprehension. Did this release of the project live up to that expectation? Nope. Could others have done a better job? Maybe, maybe not. Could this project improve over time? Certainly. Will Dart become a JavaScript killer without more magic in its cross-compiler? Personally, I doubt it. Tooling may matter for developing large web apps, but performance matters in those large web apps too; running this test in my iPhone's browser leaves me feeling meh.
- bane 15y ago
  It is improbably in my mind that we've reached an age where javascript is considered low level -- even tongue in cheek. I wonder where this is on the path to the singularity?
- Tloewald 15y ago
  It makes me think that dart would be a perfect language in which to re-implement OpenDoc.
swannodette 15y ago
http://jsperf.com/dart-hello-world-test-with-optimize/5 http://jsperf.com/dart-hello-world-test-with-optimize/5 I moved things around so that what code does is roughly equivalent. As you can see Dart is slower, but the Dart runtime does not differ by a margin that matters for many applications - and note the size of the gap differs significantly between JS engines.
- cdata 15y ago
  In all fairness, you removed the actual print function from the code. Inspection of the non-compiled source suggests that the entire function execution as shown in /2 is called for every call to Dart's print. print$getter()(1, $noargs, 'Hello, Dart!'); print$getter()(1, $noargs, 'foo'); print$getter()(1, $noargs, 'bar');
  - swannodette 15y ago
    I did not remove print. Google Closure Compiler does inlining as well.

cdata 15y ago

Let's be realistic with ourselves here: is all that overhead ever going to compete with ten lines of "low level" (ha..) JavaScript? No. The problem here, and what is making us chuckle so much, is that the project as presented to us is not magical. For whatever reason, some of the brightest minds in our industry have not presented us (at this time) with a cross-compiler that is both robust enough to support large apps, and intelligent enough to self-optimize its output. Were we expecting a JavaScript killer from Google? Some of us were, with cynical apprehension. Did this release of the project live up to that expectation? Nope. Could others have done a better job? Maybe, maybe not. Could this project improve over time? Certainly. Will Dart become a JavaScript killer without more magic in its cross-compiler? Personally, I doubt it. Tooling may matter for developing large web apps, but performance matters in those large web apps too; running this test in my iPhone's browser leaves me feeling meh.

bane 15y ago
It is improbably in my mind that we've reached an age where javascript is considered low level -- even tongue in cheek. I wonder where this is on the path to the singularity?
Tloewald 15y ago
It makes me think that dart would be a perfect language in which to re-implement OpenDoc.

swannodette 15y ago

http://jsperf.com/dart-hello-world-test-with-optimize/5 http://jsperf.com/dart-hello-world-test-with-optimize/5 I moved things around so that what code does is roughly equivalent. As you can see Dart is slower, but the Dart runtime does not differ by a margin that matters for many applications - and note the size of the gap differs significantly between JS engines.

cdata 15y ago
In all fairness, you removed the actual print function from the code. Inspection of the non-compiled source suggests that the entire function execution as shown in /2 is called for every call to Dart's print. print$getter()(1, $noargs, 'Hello, Dart!'); print$getter()(1, $noargs, 'foo'); print$getter()(1, $noargs, 'bar');
- swannodette 15y ago
  I did not remove print. Google Closure Compiler does inlining as well.