js importing problem

[Dr J R Stockton]

In comp.lang.javascript message <[email protected].

Why is that?

Ignore him. For a new JavaScripter, machine efficiency is of minor
importance; what matters is that you, and maybe others, can read your
code easily.

The chief purpose of composing strings is to have then displayed and
read. Only for strings of many lines is it possible for the "joining"
part of composing to take time significant in comparison with the time
taken to display them; and on any recent machine (clock speed over about
2 MHz), it is reading which will take by far the longest time.

However,
var msg = "this " + "that " +
"tother"
is easier to type.

Code should be indented by about two spaces per unclosed "{" to show
intended structure, if it is intended to be read by people (including
yourself, later). A considerate commercial site will strip that, and
most other comment, from the publicly-distributed version.

 

[Thomas 'PointedEars' Lahn]

JSLitmus eh? First time I've run across that particular gem.

And that is good so, because it is junk. I'm sure David will gladly explain
why.

I think I have a new hobby.

Writing a speed test that doesn't contain such blunders as browser sniffing
and augmenting prototype objects?


PointedEars

 

[Gregor Kofler]

FF 3.0.8 Intrepid AMD64

Browser "freshly" restarted:
Firebug enabled:
add 1121 (0.89ms)
join 685 (1.46ms)

Firebug disabled:
add 997 (1ms)
join 1004 (1ms)

3rd or 4th re-run:

Firebug enabled:
add 587 (1.7ms)
join 932 (1.07ms)

Firebug disabled:
add 566 (1.77ms)
join 684 (1.46ms)

Analyze this...

Those benchmarks are pretty, but the results - particularly in FF vary so
wildly - that they are rather useless.

Gregor

 

[Jeremy J Starcher]

And that is good so, because it is junk. I'm sure David will gladly
explain why.


Writing a speed test that doesn't contain such blunders as browser
sniffing and augmenting prototype objects?

Are you sure that you and I are looking at the same code?

The browser sniffing is only used for screen reporting. A nicety, hardly
a sin.

I don't see augmenting prototype objects.

The only augmentation I see appears to be of the jsl itself.

 

[Jorge]

Analyze this...

Those benchmarks are pretty, but the results - particularly in FF vary so
wildly - that they are rather useless.

Yes, I have seen that before:

1.- Enabling Firebug affects execution speed.
2.- it also slows down when garbage collection cycles kick in.

....but both happen (are observable) regardless of the method used for
timing: IOW, I don't think that it's JSLitmus' fault.

 

[Thomas 'PointedEars' Lahn]

And that is good so, because it is junk. I'm sure David will gladly explain
why.

Writing a speed test that doesn't contain such blunders as browser sniffing
and augmenting prototype objects?

Looking at JSLint source [1],

JSLitmus, not JSLint (I presume the latter to be of better quality, but I
might be wrong). And what matters here is not the original source but what
Jorge made of it. You only need to use the URI-reference that is the `src'
attribute value.

I don't see `navigator.userAgent` being used for anything except diagnostic
output.

There is no good reason to use it at all.

From the cursory overview, there seems to be no object inference either.

And what do you make of this?

// Detect OS
var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS X','Linux'].join('|');
var pOS = new RegExp('((' + oses + ') [^ \);]*)').test(ua) ? RegExp.$1 : null;
if (!pOS) pOS = new RegExp('((' + oses + ')[^ \);]*)').test(ua) ?
RegExp.$1 : null;

// Detect browser
var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1 : null;

I also don't see prototype objects augmentation (if you meant prototypes
of built-in native objects, of course, and not user defined once).

// IE workaround - monkey patch Array.indexOf() if it's not defined
if (!Array.prototype.indexOf) {
Array.prototype.indexOf = function(o) {
for (var i = 0; i < this.length; i++) if (this === o) return i;
return -1;
}
}

That precludes Array objects from being subject to a realistic benchmark.

Explain?

Polite people say please.

Are there any major mistakes in the script that I'm not seeing?

Yes.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Are you sure that you and I are looking at the same code?

My Magic 8 Ball says: Don't count on it.

The browser sniffing is only used for screen reporting. A nicety, hardly
a sin.

An unnecessity, at best.

I don't see augmenting prototype objects.

Look closer.

The only augmentation I see appears to be of the jsl itself.

The *what*?


PointedEars

 

[Jeremy J Starcher]

Jeremy J Starcher wrote:
JSLitmus eh? First time I've run across that particular gem.
And that is good so, because it is junk. I'm sure David will gladly
explain why.

I think I have a new hobby.
Writing a speed test that doesn't contain such blunders as browser
sniffing and augmenting prototype objects?

Looking at JSLint source [1],

JSLitmus, not JSLint (I presume the latter to be of better quality, but
I might be wrong). And what matters here is not the original source but
what Jorge made of it. You only need to use the URI-reference that is
the `src' attribute value.

Since the discussion was on JSLitmus, doesn't the original source matter
more?

kangax and I are referring to the code from:

I don't see `navigator.userAgent` being used for anything except
diagnostic output.

There is no good reason to use it at all.

From the cursory overview, there seems to be no object inference
either.

And what do you make of this?

// Detect OS
var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS
X','Linux'].join('|'); var pOS = new RegExp('((' + oses + ') [^
\);]*)').test(ua) ? RegExp.$1 : null; if (!pOS) pOS = new RegExp('(('
+ oses + ')[^ \);]*)').test(ua) ?
RegExp.$1 : null;

// Detect browser
var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1
: null;

Used for *display* *purposes* *only.*

I also don't see prototype objects augmentation (if you meant
prototypes of built-in native objects, of course, and not user defined
once).

// IE workaround - monkey patch Array.indexOf() if it's not defined if
(!Array.prototype.indexOf) {
Array.prototype.indexOf = function(o) {
for (var i = 0; i < this.length; i++) if (this === o) return i;
return -1;
}
}

And this code comes from .... Oh yes. A modified version of the JSLitmus
test. Not useful for discussing JSLitmus itself.

var jsl = {

[ code snipped ]

/**
* Array#indexOf isn't supported in IE, so we use this as a cross-
browser solution
*/
indexOf: function(arr, o) {
if (arr.indexOf) return arr.indexOf(o);
for (var i = 0; i < this.length; i++) if (arr === o) return i;
return -1;
}

[ More code snipped ]
}

No modification of Array object.

That precludes Array objects from being subject to a realistic
benchmark.

Again, not valid against the original source.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Jeremy J Starcher wrote:
JSLitmus eh? First time I've run across that particular gem.
And that is good so, because it is junk. I'm sure David will gladly
explain why.

I think I have a new hobby.
Writing a speed test that doesn't contain such blunders as browser
sniffing and augmenting prototype objects?
Looking at JSLint source [1],

JSLitmus, not JSLint (I presume the latter to be of better quality, but
I might be wrong). And what matters here is not the original source but
what Jorge made of it. You only need to use the URI-reference that is
the `src' attribute value.

Since the discussion was on JSLitmus, doesn't the original source matter
more?

The discussion was about the reliability of Jorge's benchmarks. It is you
original who is trying to make it a discussion about the benchmarking script.

kangax and I are referring to the code from:
< http://www.broofa.com/Tools/JSLitmus/demo_test.html >

Well, I'm not.

I don't see `navigator.userAgent` being used for anything except
diagnostic output.

There is no good reason to use it at all.

From the cursory overview, there seems to be no object inference
either.

And what do you make of this?

// Detect OS
var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS
X','Linux'].join('|'); var pOS = new RegExp('((' + oses + ') [^
\);]*)').test(ua) ? RegExp.$1 : null; if (!pOS) pOS = new RegExp('(('
+ oses + ')[^ \);]*)').test(ua) ?
RegExp.$1 : null;

// Detect browser
var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1
: null;

Used for *display* *purposes* *only.*

Nevertheless of questionable quality and usefulness.

I also don't see prototype objects augmentation (if you meant
prototypes of built-in native objects, of course, and not user defined
once).

// IE workaround - monkey patch Array.indexOf() if it's not defined if
(!Array.prototype.indexOf) {
Array.prototype.indexOf = function(o) {
for (var i = 0; i < this.length; i++) if (this === o) return i;
return -1;
}
}

And this code comes from .... Oh yes. A modified version of the JSLitmus
test.

Or an older version. In any case, Jorge is to blame for using it an
presenting it as a telltale benchmark.

Not useful for discussing JSLitmus itself.

See above.

var jsl = {

[ code snipped ]

/**
* Array#indexOf isn't supported in IE, so we use this as a cross-
browser solution
*/
indexOf: function(arr, o) {
if (arr.indexOf) return arr.indexOf(o);
for (var i = 0; i < this.length; i++) if (arr === o) return i;
return -1;
}

[ More code snipped ]
}

No modification of Array object.

(It would have been the "Array.prototype object".) And that is good so.

Again, not valid against the original source.

Again, irrelevant to my case.


PointedEars

 

[Thomas 'PointedEars' Lahn]

The discussion was about the reliability of Jorge's benchmarks. It is you
original who is trying to make it a discussion about the benchmarking script.

^^^^^^^^
That "original" must have gotten in there by accidental copy-paste.
No offense meant.


PointedEars

 

[Jorge]

The discussion was about the reliability of Jorge's benchmarks.  It is you
original who is trying to make it a discussion about the benchmarking script.
(...)

JFTR both versions yield the same results:

The one with an older, modified JSLitmus:
http://jorgechamorro.com/cljs/053/

And the "The PointedEars is an idiot" version, with the latest version
of JSLitmus (untouched):
http://jorgechamorro.com/cljs/054/

PointedEars: could you get back to study the closures now please ?

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote: [...]
Writing a speed test that doesn't contain such blunders as browser sniffing
and augmenting prototype objects?
Looking at JSLint source [1],

JSLitmus, not JSLint (I presume the latter to be of better quality, but I

That was a typo on my part

might be wrong). And what matters here is not the original source but what
Jorge made of it. You only need to use the URI-reference that is the `src'
attribute value.

Ok. It seemed like you were talking about JSLitmus.js script itself.

I was referring to the JSLitmus.js referred in the HTML source of Jorge's
"benchmark". Why should I be referring to something else if the quality of
the "benchmark" is in question?

But it's not being *used* (as in affecting any execution logic/outcome).
It's being merely *displayed* to the user.

Maybe so.

[...]

`pName` is only displayed to the user, AFAICS, just like the value of
`navigator.userAgent` (among others `navigator` properties) is displayed
on one of your pages - http://pointedears.de/scripts/test/whatami/.

I really don't see what's wrong with it.

A simple navigator.userAgent can do it much better.

The file I linked to has something else (formatted to fit the width) -
[...]

Of course.


PointedEars

 

[Jorge]

I was referring to the JSLitmus.js referred in the HTML source of Jorge's
"benchmark".  Why should I be referring to something else if the quality of
the "benchmark" is in question?

JFTR, in the cljs message:
http://groups.google.com/group/comp.lang.javascript/msg/fc4da5be3a9f305a

 

[Tad J McClellan]

Efficiency reasons.

I optimize to reduce whatever is most expensive.

Cycles are cheap.

Memory is cheap.

Programmers are expensive (though we may think we're not expensive
enough when payday rolls around).

Therefore, I optimize for maintenance first, and would write:

var msg = "Hello";
msg += " ";
msg += "there";

because it is immediately apparent what the code is doing.

var msg = "Hello" +
" " +
"there";

I would write that as:

var msg = "Hello"
+ " "
+ "there";

However, this tends to be the fastest in most user agents (particularly
if the resultant string is quite large).

var msgs = []
msgs.push("Hello");
msgs.push(" ");
msgs.push("there");
msg = msgs.join("");

"Premature optimization is the root of all evil"


I write for efficient maintenance.

Only if it then proves too slow would I think about writing for
execution speed.

 

[Lasse Reichstein Nielsen]

Efficiency reasons.

var msg = "Hello";
msg += " ";
msg += "there";

is computationally expensive because string objects are created and
destroyed with each step.

That depends entirely on the implementation.

Most implementations (i.e., probably anything but IE, and I don't know
about IE 8) have efficient (constant time) string concatenation.

It's only if you start using the string that the string is flattened.

From the way I read the specs, this isn't any better.

var msg = "Hello" +
" " +
"there";

The spec doesn't say anything about the representation of strings, nor
their performance characteristics. It is probably the same as the former,
though.

However, this tends to be the fastest in most user agents (particularly
if the resultant string is quite large).

var msgs = []
msgs.push("Hello");
msgs.push(" ");
msgs.push("there");
msg = msgs.join("");

This is a classical trick to avoid expensive (quadratic time
complexity) string concatentation. These days it's only really needed
in IE (but that does mean that it's needed!), and I wouldn't use it
unless the addition was in a loop and with a potentially large result.
For something with a result of eleven characters, it's probably more
expensive that just doing the additions.

It's actually what non-IE browsers do, behind the scene, anyway.

For something like this tiny example, the programmatic complexity
increase far outweighs the computational complexity improvement. (Or,
in other words: Don't optimize unless it's necessary. Don't think it's
necessary unless you have measured it.)

/L