By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,847 Members | 3,242 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,847 IT Pros & Developers. It's quick & easy.

JavaScript implementation

P: n/a

What is the shortest and simplest Javascript implementation and where can I
find a BNF for this language?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Sep 20 '08 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Jon Harrop <jo*@ffconsultancy.comwrites:
What is the shortest and simplest Javascript implementation and where can I
find a BNF for this language?
Shortest and simplest .. no idea.
Try looking at any of:
http://www.mozilla.org/js/spidermonkey/
http://www.mozilla.org/rhino/
http://webkit.org/projects/javascript/
http://code.google.com/p/v8/
and determine for yourself which is shortest or simplest.

The BNF is in the ECMAScript standard:
http://www.mozilla.org/js/language/E262-3.pdf

Enjoy
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Sep 21 '08 #2

P: n/a
Lasse Reichstein Nielsen wrote:
Jon Harrop <jo*@ffconsultancy.comwrites:
>What is the shortest and simplest Javascript implementation and where can
I find a BNF for this language?

Shortest and simplest .. no idea.
Thanks for the links. Here are my findings:
Try looking at any of:
http://www.mozilla.org/js/spidermonkey/
SpiderMonkey is a JavaScript interpreter written in 100kLOC of C.
http://www.mozilla.org/rhino/
Rhino is is a JavaScript interpreter written in 41kLOC of Java.
http://webkit.org/projects/javascript/
Webkit's JavaScriptCore is is a JavaScript interpreter written in 68kLOC of
C++.
http://code.google.com/p/v8/
Google's V8 is a native code JavaScript compiler written in 77kLOC of C++.
and determine for yourself which is shortest or simplest.
Google provide a Javascript benchmark suite with V8 that I had some fun
playing with. Konqueror's Javascript implementation gets a score of 12,
Microsoft IE 7 gets 20, Mozilla Firefox gets 120 and V8 gets a whopping
1,270!
The BNF is in the ECMAScript standard:
http://www.mozilla.org/js/language/E262-3.pdf
Thanks!

May I ask, do many people find JavaScript performance to be important? I
certainly wish my browsers were faster (more Konqueror and Mozilla rather
than MSIE) but I am not sure that can be attributed to the JavaScript
implementation...

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Sep 21 '08 #3

P: n/a
Jon Harrop wrote:
Google provide a Javascript benchmark suite with V8 that I had some fun
playing with. Konqueror's Javascript implementation gets a score of 12,
Microsoft IE 7 gets 20, Mozilla Firefox gets 120 and V8 gets a whopping
1,270!
Unsurprisingly, as we discussed before, those benchmark results are flawed.
>The BNF is in the ECMAScript standard:
http://www.mozilla.org/js/language/E262-3.pdf

[...]
May I ask, do many people find JavaScript performance to be important?
That is a pointless question.

I would presume *competent developers* regard the performance of their
applications to be important.
I certainly wish my browsers were faster (more Konqueror and Mozilla rather
than MSIE) but I am not sure that can be attributed to the JavaScript
implementation...
Probably the rendering speed of the user agent's layout engine is more
important than the speed of the script engine as the former determines how
fast script operations manifest themselves. That does not mean, though,
that the efficiency of script code is unimportant.

The term "JavaScript implementation" is a misnomer, BTW. If anything,
Netscape/Mozilla.org JavaScript, Microsoft JScript & Co. are *ECMAScript*
implementations.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.
Sep 21 '08 #4

P: n/a
Thomas 'PointedEars' Lahn wrote:
Jon Harrop wrote:
>Google provide a Javascript benchmark suite with V8 that I had some fun
playing with. Konqueror's Javascript implementation gets a score of 12,
Microsoft IE 7 gets 20, Mozilla Firefox gets 120 and V8 gets a whopping
1,270!

Unsurprisingly, as we discussed before, those benchmark results are
flawed.
Do you mean this thread:

http://groups.google.com/group/comp....b0b7218749f790

Or is there a more thorough discussion?
>>The BNF is in the ECMAScript standard:
http://www.mozilla.org/js/language/E262-3.pdf

[...]
May I ask, do many people find JavaScript performance to be important?

That is a pointless question.
Let me rephrase: would a more performant ECMAScript implementation be of
much interest or value?
>I certainly wish my browsers were faster (more Konqueror and Mozilla
rather than MSIE) but I am not sure that can be attributed to the
JavaScript implementation...

Probably the rendering speed of the user agent's layout engine is more
important than the speed of the script engine as the former determines how
fast script operations manifest themselves. That does not mean, though,
that the efficiency of script code is unimportant.
That's what I thought.
The term "JavaScript implementation" is a misnomer, BTW. If anything,
Netscape/Mozilla.org JavaScript, Microsoft JScript & Co. are *ECMAScript*
implementations.
Thanks.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Sep 21 '08 #5

P: n/a
Jon Harrop wrote:
Thomas 'PointedEars' Lahn wrote:
>Jon Harrop wrote:
>>Google provide a Javascript benchmark suite with V8 that I had some fun
playing with. Konqueror's Javascript implementation gets a score of 12,
Microsoft IE 7 gets 20, Mozilla Firefox gets 120 and V8 gets a whopping
1,270!
Unsurprisingly, as we discussed before, those benchmark results are
flawed.

Do you mean this thread:

http://groups.google.com/group/comp....b0b7218749f790
Yes.
Or is there a more thorough discussion?
None that I know of.
>>>The BNF is in the ECMAScript standard:
http://www.mozilla.org/js/language/E262-3.pdf
[...]
May I ask, do many people find JavaScript performance to be important?
That is a pointless question.

Let me rephrase: would a more performant ECMAScript implementation be of
much interest or value?
My Magic 8-Ball says: "Most likely".
HTH

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Sep 21 '08 #6

P: n/a
On Sep 21, 4:55 pm, Jon Harrop <j...@ffconsultancy.comwrote:
>
Google provides a Javascript benchmark suite with V8 that I had some fun
playing with. Konqueror's Javascript implementation gets a score of 12,
Microsoft IE 7 gets 20, Mozilla Firefox gets 120 and V8 gets a whopping
1,270!
The latest Webkit with SFX scores almost 6x better: in my Mac: before:
186 (Safari 312), now 1086 (Wewbkit r36712), Chrome/V8: 2665.

John resig has setup another benchmark suite: http://dromaeo.com.
>
May I ask, do many people find JavaScript performance to be important? I
certainly wish my browsers were faster (more Konqueror and Mozilla rather
than MSIE) but I am not sure that can be attributed to the JavaScript
implementation...
It depends: how much time does your page spend running JS code ?

A page with no JS: nothing.
A page that computes DNA regexps: a lot.
A page that expends 50% of the time computing, and 50% of the time
manipulating/rearranging the DOM (laying out/rendering): a 100%
improvement in JS peformance (2x JS speedud), would speed it up by
25%...

The rendering/layout engine performance is a factor, the other one is
the JS interpreter's. Oh, well, and the network speed as well...hehe.
Isn't it ?

--
Jorge.
Sep 21 '08 #7

P: n/a
Jorge wrote:
On Sep 21, 4:55 pm, Jon Harrop <j...@ffconsultancy.comwrote:
....
>May I ask, do many people find JavaScript performance to be
important? I certainly wish my browsers were faster (more Konqueror
and Mozilla rather than MSIE) but I am not sure that can be
attributed to the JavaScript implementation...

It depends: how much time does your page spend running JS code ?

A page with no JS: nothing.
A page that computes DNA regexps: a lot.
A page that expends 50% of the time computing, and 50% of the time
manipulating/rearranging the DOM (laying out/rendering): a 100%
improvement in JS peformance (2x JS speedud), would speed it up by
25%...

The rendering/layout engine performance is a factor, the other one is
the JS interpreter's. Oh, well, and the network speed as well...hehe.
Isn't it ?
Good summary. I am interested in js-performance, but I am writing
js-programs for the general public. Users have their browsers already,
and persuading them to switch to another browser to get speed is not an
option.

I was astonished to see that the most simple js-statements are very fast
even in
old computers: even 1 000 000 lines per second. But as soon as
any DOM-manipulation are done, statements slow down 10 or 100 times.

The talk about 'performance' or 'efficiency' is sometimes very amusing:
a person might try to save with special coding one microsecond
(= 0.000 001 seconds) per page loading , but does not think
about using milliseconds (=0.001 s) or even
hundreds of milliseconds elsewhere on the same page.

If the page loading takes 5 000 000 microseconds, is there any sense
to write about saving 1 microsecond?

Sep 22 '08 #8

P: n/a
"optimistx" <op*************@poistahotmail.comwrites:
If the page loading takes 5 000 000 microseconds, is there any sense
to write about saving 1 microsecond?
As with all optimizations: Don't do it, until you have determined (by
profiling) that it is going to help.

Most of your code is not critical to performance. E.g., anything not
inside a loop is unlikely to be important.

"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity." - W.A. Wulf

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Sep 22 '08 #9

P: n/a
On Sep 22, 4:24*am, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
If the page loading takes 5 000 000 microseconds, is there any sense
to write about saving 1 microsecond?
That depends what you mean by page loading. Technically, I suppose
that it would mean all javascript and html executed before the onload
event. This would include such considerations as download speed of
images and include files which are certainly beyond the help of the
javascript engine.

If, on the other hand, you mean javascript setup code that executes
after the onload, then the efficiency of your javascript engine
becomes very important. I have been doing benchmarking of IE 8 Beta
2. In the area of pure string concatenation, I have measured a 50x
speed up. This is a very big deal to some folks with lots of legacy
code. I could rewrite that code to use temporary arrays and join and
I'd get my own speed-up but not close to 50x.

To the user, it all looks like "loading" time and in my case, the
difference is between 3 minutes and something under 20 seconds. And
before the anti-IE forces attack, the nature of the company and site
(private) is all IE, all the time, ActiveX required, nothing I can do
about it so don't start.

Bob
Sep 22 '08 #10

P: n/a
On Sep 22, 9:24*am, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
If the page loading takes 5 000 000 microseconds, is there any sense
to write about saving 1 microsecond?
There may be. Many of my pages call little or no JavaScript during
load, but use input type=text to set up a calculation and input
type=button to start it. The ange of times that the calculation is
expected to take is from "too fast to see" to *millennia*. Somewhere
in between, speed matters.

You may wonder why there should be code that takes millennia. The
answer is that in a good browser it takes millennia, in a bad one a
few minutes. In this specific case, IE and Firefox are good, Chrome
is bad, Opera and Safari are not so bad, and are expected to take
hours. See js-randm.htm "Repeat Interval".

Verifying the Date of Easter or ISO Week Numbers, each over the full
repeat range, provide other examples where computation speed matters.

--
(c) John Stockton, near London, UK. Posting with Google.
Mail: J.R.""""""""@physics.org or (better) via Home Page at
Web: <URL:http://www.merlyn.demon.co.uk/>
FAQish topics, acronyms, links, etc.; Date, Delphi,
JavaScript, .....|

Sep 22 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.