Hello,

I am puzzled by some indentation expectations that I am getting from JSLint.  I
was wondering if somebody might clarify this?  Please consider this code:

/*jslint white: true, maxlen: 80, indent: 4 */

var TEST1 = {

````// Does not show errors... why?
````someMethod1: function () {
````````return "Test1a";
````},

````someLongString: 'This is a long string that I want to wrap. My ' +
````````'minimizer will handle this nicely. This might wrap for several ' +
````````'lines, who knows?',

````// Shows errors... why?
````someMethod2: function () {
````````return "Test1b";
````}
};

As you can see, I have a property called "someLongString" which ends up wrapping
because it is so long.  I indent it because it wraps (if I don't, different
errors appear).

Any additional multi-line properties that are defined in the same object AFTER
the long string are now expected to indent one additional level.  Multi-line
properties defined before the long string do not have to indent.

Is there something wrong with my indentation here?  I would like to comply with
strict white spacing, but I don't understand the reasoning behind this change. 
It seems unusual to change indentation schemes in the middle of an object
definition just because one of the properties wraps.

Any advice on this?

Thanks!

- Chris

We have been using an older version of JSLint ('2010-12-14') to validate code
like the below. This has been going well, but when trying to upgrade to newest
version ('2011-04-04'), the validation goes not so well.

We have tried it out on the online edition, and get the same mysterious error.

Can anybody help us out?

Thanks,
Rolf Njor Jensen

The options for JSLint:
/*jslint adsafe: true, safe: true, fragment: true, undef: true, regexp: true,
strict: true, maxerr: 50, indent: 4 */

The input:
<div id="APP_">
<script>"use strict";ADSAFE.id("APP_");</script>
<script>ADSAFE.go(
"APP_",
function(){
/**
  * The lib object is configured with properties and
  * methods according to the components "capabilities".
  * @param {object} lib
  */
function Component ( lib ) {

  return {

   /**
    * Invoked when elem ent is first introduced (on page load or by AJAX update)
    * @param {object} dom The ADsafe dom wrapper
    */
   onload : function ( dom ) {},

   /**
    * Invoked whenever new data is found in the public RDF datasource.
    * @param {boolean} isIndexed True when data was indexed by RDFa in the page
DOM.
    */
   ondata : function ( isIndexed ) {},

   /**
    * Invoked before element is updated (AJAX update)
    */
   onbeforeupdate : function () {},

   /**
    * Invoked after element is updated (AJAX update)
    * @param {object} dom The ADsafe dom wrapper.
    */
   onafterupdate : function ( dom ) {},

   /**
    * Invoked on window.unload
    */
   onunload : function () {}
  };
}
var foo = new Component();
foo.doStuff();
});
</script></div>

I have found that wrapping complex or intermediates in parens makes JSLint
happy, also if I am doing a stacked var with complex declarations I have found
it is necessary to place each variable on a separate line with indentation.

var
	 i = (
		 $('<p></p>')
			 .css({width: '100%', height: '200px'})
	 ),
	 o = (
		 $('<div></div>')
			 .css(
				 {
					 position: 'absolute',
					 top: '0',
					 left: '0',
					 visibility: 'hidden',
					 width: '200px',
					 height: '150px',
					 overflow: 'hidden'
				 }
			 )
	 );

view with fixed font.

--- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
>
> I turned on strict whitespace and jslint is telling me that the section
> starting with `position: 'absolute'` should be have one fewer tab stops:
>
> var i = $('<p></p>')
>
>       .css({width: '100%', height: '200px'}),
>
>    o = $('<div></div>')
>
>       .css({
>
>          position: 'absolute',
>
>          top: '0',
>
>          left: '0',
>
>          visibility: 'hidden',
>
>          width: '200px',
>
>          height: '150px',
>
>          overflow: 'hidden'
>
>       }),
>
>    w1,
>
>    h1,
>
>    w2,
>
>    h2;
>
> Does my indentation need improvement or does the way I've done it make
> sense?
>
> Erik
>
>
> [Non-text portions of this message have been removed]
>

--- In jslint_com@yahoogroups.com, "rolfnjorjensen_tradeshift" <rnj@...> wrote:
>
> We have been using an older version of JSLint ('2010-12-14') to validate code
like the below. This has been going well, but when trying to upgrade to newest
version ('2011-04-04'), the validation goes not so well.
>
> We have tried it out on the online edition, and get the same mysterious error.

JSLint now inspects the signatures of the functions passed to .id and .go.

So

     ADSAFE.go("APP_", function () {

should have been

     ADSAFE.go("APP_", function (dom, lib) {

The messaging was not very helpful and has been improved.

I recommend always using the latest version. Sometimes researchers provide
suggestions which are constantly strengthening the system.

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
> I am puzzled by some indentation expectations that I am getting from JSLint. 
I was wondering if somebody might clarify this?  Please consider this code:
>
> /*jslint white: true, maxlen: 80, indent: 4 */
>
> var TEST1 = {
>
> ````// Does not show errors... why?
> ````someMethod1: function () {
> ````````return "Test1a";
> ````},
>
> ````someLongString: 'This is a long string that I want to wrap. My ' +
> ````````'minimizer will handle this nicely. This might wrap for several ' +
> ````````'lines, who knows?',
>
> ````// Shows errors... why?
> ````someMethod2: function () {
> ````````return "Test1b";
> ````}
> };
>
> As you can see, I have a property called "someLongString" which ends up
wrapping because it is so long.  I indent it because it wraps (if I don't,
different errors appear).
>
> Any additional multi-line properties that are defined in the same object AFTER
the long string are now expected to indent one additional level.  Multi-line
properties defined before the long string do not have to indent.
>
> Is there something wrong with my indentation here?  I would like to comply
with strict white spacing, but I don't understand the reasoning behind this
change.  It seems unusual to change indentation schemes in the middle of an
object definition just because one of the properties wraps.


Thanks. Please try it now.

Just ran into this. The scenario, now using a small sample:

Copy&paste this code into the edit area at jslint.com:

- - - - - - -
// TAB is `
var dummy_sample = {
`decode: function(s) {
``s = s.replace(/\$/g, '%');
``s = decodeURIComponent(s);
``return s;
`},
`removeListener: function(listenerID) { // use the interval ID returned by
addListener
``return clearInterval(listenerID);
`}
};
- - - - - - -

after you've replaced the ` with TAB (ASCII 09) characters.

Tick the 'Disallow undefined variables' and 'Assume a browser' checks and
run jsLint.

Expected result: ZERO errors.


At the bottom of the page, this jslint config comment is shown:

- - - - - - -
/*jslint undef: true, browser: true, maxerr: 50, indent: 4 */
- - - - - - -

which we now include in the code:

- - - - - - -
/*jslint undef: true, browser: true, maxerr: 50, indent: 4 */

// TAB is `
var dummy_sample = {
`decode: function(s) {
``s = s.replace(/\$/g, '%');
``s = decodeURIComponent(s);
``return s;
`},
`removeListener: function(listenerID) { // use the interval ID returned by
addListener
``return clearInterval(listenerID);
`}
};
- - - - - - -

and then run jsLint again. (Either with those two checkmarks still ticked or
not, doesn't matter.)

Expected result: zero errors.
Observed result: 2 errors!


What led to this: the idea that copy&pasting that /*jslint*/ line into the
code itself would, at a later date, reproduce the jsLint run exactly.
Without the need to manually set/reset the ticks outside the site defaults.


Diag:

I expected the /*jslint*/ line to override (only) the mentioned items, but
it _seems_ all unmentioned options are also overridden, and oddly enough,
those seem to be treated as 'true' (checked) all of a sudden. For example,
'strict whitespace' may show up as unchecked, but the /*jslint*/ line above
implicitly sets that one to 'true' under the hood.

The result: only adding the /*jslint*/ line in the code to be linted
completely changes the report.



Haven't inspected the site's sourcecode, so can't quote number and verse
where this is happening, sorry.


--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
         http://www.hebbut.net/
mail:   ger@...
mobile: +31-6-11 120 978
--------------------------------------------------


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Ger Hobbelt <ger@...> wrote:

> The result: only adding the /*jslint*/ line in the code to be linted
> completely changes the report.
>
> Haven't inspected the site's sourcecode, so can't quote number and verse
> where this is happening, sorry.

The option object is used to determine the settings. It is overridden by the
/*jslint*/ directive. Any setting that is not mentioned in either is assumed to
be false.

On Sat, Apr 9, 2011 at 2:27 PM, Douglas Crockford <douglas@...>wrote:

> The option object is used to determine the settings. It is overridden by
> the /*jslint*/ directive. Any setting that is not mentioned in either is
> assumed to be false.
>

Yeah, that's what I thought. Still, we might talk about slightly different
things here and what you say does not match the behaviour I'm observing:

Note, please, that I mention the jslint.com *website* so it's not an issue
with the jslint standalone script, but with the jslint.com website only!
  Using the sample code I provided, it actually (on the site!) behaves like
this: (>>>><<<< emphasis mine)

test case #1:

NOT providing any /*jslint*/ line with the code to be linted.

Result: behaves exactly as when you'ld have this at the top: (1 error)
/*jslint undef: false, browser: false, maxerr: 50, indent: 4, white:
>>>>false<<<< */

Good.


test case #2:

manually ticking the 'disallow unused variables' and 'assume browser' items;
NOT any /*jslint*/ in the code.

Result: behaves exactly as when you'ld have this at the top: (no errors)
/*jslint undef: true, browser: true, maxerr: 50, indent: 4, white:
>>>>false<<<< */

Good.

Note that the /*jslint*/ shown at the bottom of the web page now says:
/*jslint undef: true, browser: true, maxerr: 50, indent: 4 */



Assumption: copying that /*jslint*/ line into the code should behave like #2
again, as we wouldn't really change _anything_; just copying the options
block settings into the code.
So:


test case #3:

This /*jslint*/ at the top of the code:
/*jslint undef: true, browser: true, maxerr: 50, indent: 4 */

Result: behaves exactly as when you'ld have this at the top:
/*jslint undef: true, browser: true, maxerr: 50, indent: 4, white:
>>>>true<<<< */

*BAD*

I did NOT set the 'strict whitespace' setting _anywhere_ on that page, yet
it automagically kicks in now. I _have_ to explicitly add 'white: false' in
the /*jslint*/ to get the #2 behaviour again.



test case #4:

This /*jslint*/ at the top of the code:
/*jslint undef: true, browser: true, maxerr: 50, indent: 4, white:
>>>>false<<<< */

Result: behaves exactly like #2.

Good.



Unless I completely misunderstood, then this behaviour (#3 vs. #2 & #1) is
not matching

> The option object is used to determine the settings. It is overridden by
> the /*jslint*/ directive. Any setting that is not mentioned in either is
> assumed to be false.
>
> as 'strict whitespace' ('white') is not mentioned in the /*jslint*/
included at the top of the code, while the option section has the checkbox
_unchecked_, so it should read as 'white:false', but acts as 'white:true'
instead.  And in case you mean something else _entirely_ with the words
'option object' (and it has white:true as a preset in there), then it still
behaves counter to the rest of your line, as it should have identical
behaviour for #2 and #3 (and #1 as well, with respect to the 'strict
whitespace' setting, that is).    Looks like a bug to me. Tell me I screwed
up all the way, or can you reproduce the issue?



(Tested with both Safari5 and FF3)


--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
         http://www.hebbut.net/
mail:   ger@...
mobile: +31-6-11 120 978
--------------------------------------------------


[Non-text portions of this message have been removed]

Is anyone using the Assume a Yahoo Widget option?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> Is anyone using the Assume a Yahoo Widget option?
>

I do, all the time, for both my own coding and for maintaining the Widget Tester
Widget.

Harry.

Apologies if I missed an announcement, but does JSLint no longer warn about
having a line break before the operator e.g.

function g() {
   var a = 4
     + 5;
}

results in no relevant warnings.

I was trying to find out whether the error was style or because of automatic
semicolon insertion and discovered the error missing.


[Non-text portions of this message have been removed]

At the end, where jslint displays all the used properties of objects that
it's noticed, the display is showing less-than characters encoded in
javascript string style. Is this expected?

For example, if I do something like this:

buildHtml({
   "<br />An important label": someobject.starttime.toString()
});

Then in the properties, I see this:

/*properties $1,
     "\u003cbr \/>An important label"


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
>
> At the end, where jslint displays all the used properties of objects that
> it's noticed, the display is showing less-than characters encoded in
> javascript string style. Is this expected?
>
> For example, if I do something like this:
>
> buildHtml({
>   "<br />An important label": someobject.starttime.toString()
> });
>
> Then in the properties, I see this:
>
> /*properties $1,
>     "\u003cbr \/>An important label"

Since the report is in HTML, the only other option would be to use an entity.
But that means, for some browsers, that you cannot copy the properties report
into a program.

Classification: UNCLASSIFIED

> Since the report is in HTML, the only other option would be to use an entity.
But that means, for some browsers, that you cannot copy the properties report
into a program.

What kind of problems are you encountering?  I thought I had written a perfectly
stable solution for the text output of diffs for Pretty Diff.  Either there
exists a test case that I am neglecting or I have a working solution that could
solve this problem.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

I'm not sure I understand this. What browser can't display a less than sign
or, when displayed can't allow it to be copied?

Are you talking about pasting the properties report directly into javascript
code, with the problem where embedded script closing tags prematurely stop
the javascript, ala:

<script type="text/javascript">
document.write('<script></script');
alert('done');
</script>

?

On Wed, Apr 13, 2011 at 5:43 AM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
> >
> > At the end, where jslint displays all the used properties of objects that
> > it's noticed, the display is showing less-than characters encoded in
> > javascript string style. Is this expected?
> >
> > For example, if I do something like this:
> >
> > buildHtml({
> > "<br />An important label": someobject.starttime.toString()
> > });
> >
> > Then in the properties, I see this:
> >
> > /*properties $1,
> > "\u003cbr \/>An important label"
>
> Since the report is in HTML, the only other option would be to use an
> entity. But that means, for some browsers, that you cannot copy the
> properties report into a program.
>
>  __._
>


[Non-text portions of this message have been removed]

The JSLint.com/index.html page now has tri-state buttons for setting options.
The states are

     black [true]
     white [false]
     gray  [undefined]

The difference between white and gray is that white sets an option to false in
the constructed /*jslint*/ directive, whilst gray does not.

Also, there has been some file renaming. fulljslint.js is now jslint.js, and
fullinit_ui.js is init_ui.js.

JSLint now reports the amount of time it took to run. These are the results that
I see on jslint.js with the Good Parts option on my laptop:

     Chrome 10.0.648.204 3.388 seconds.
     Firefox 4.0.1       1.227 seconds.
     IE 10.0.1000.16394  0.6   seconds.
     Opera 11.01         1.248 seconds.

> The JSLint.com/index.html page now has tri-state buttons for setting options.

This is a great improvement, thank you.

> Also, there has been some file renaming. fulljslint.js is now jslint.js, and
> fullinit_ui.js is init_ui.js.

Can you please update README?

--jhawk@...
   John Hawkinson

ADsafe took a big usability hit when the Firefox[-6] bug was discovered. ADsafe
took the necessary but highly undesirable step of outlawing the use of the []
subscript operator except when the subscript expression was a non-negative
number or an approved string.

Thanks to a suggestion by Jasvir Nagra, ADsafe allows [] for all number literals
as well as strings starting with '-'. It also accepts subscripts that are
expressions that can be easily determined to be strings.

adsafe.js's initialization now contains the following (which, coincidentally,
demonstrates the Principle of Correspondence):

     if (Function.__defineGetter__) {
         (function (p, f) {
             p.__defineGetter__('-1', f);
             p.__defineGetter__('-3', f);
             p.__defineGetter__('-6', f);
         }(Function.prototype, function () {
             return null;
         }));
     }

For browsers that have a __defineGetter__ method, that method will be used to
install getters for [-1], [-3], and [-6] that will return null. This is thought
to plug the Firefox leak.

JSLint will now allow subscript expressions where the outermost operator is one
of these prefix operators

     - + ~ typeof

or one of these infix operators

     - * / % & | << >> >>>

Douglas,

Can you point to the documentation/report on the Firefox[-6] bug? Just out of
curiosity.

-Kent.

On Apr 18, 2011, at 9:40 PM, Douglas Crockford wrote:

> ADsafe took a big usability hit when the Firefox[-6] bug was discovered.
ADsafe took the necessary but highly undesirable step of outlawing the use of
the [] subscript operator except when the subscript expression was a
non-negative number or an approved string.
>
> Thanks to a suggestion by Jasvir Nagra, ADsafe allows [] for all number
literals as well as strings starting with '-'. It also accepts subscripts that
are expressions that can be easily determined to be strings.
>
> adsafe.js's initialization now contains the following (which, coincidentally,
demonstrates the Principle of Correspondence):
>
> if (Function.__defineGetter__) {
> (function (p, f) {
> p.__defineGetter__('-1', f);
> p.__defineGetter__('-3', f);
> p.__defineGetter__('-6', f);
> }(Function.prototype, function () {
> return null;
> }));
> }
>
> For browsers that have a __defineGetter__ method, that method will be used to
install getters for [-1], [-3], and [-6] that will return null. This is thought
to plug the Firefox leak.
>
> JSLint will now allow subscript expressions where the outermost operator is
one of these prefix operators
>
> - + ~ typeof
>
> or one of these infix operators
>
> - * / % & | << >> >>>
>
>



[Non-text portions of this message have been removed]

http://crockford.com/javascript/performance.html

That's kind of exciting to see. Chrome's bragging is so justified,
apparently.

Douglas, what do you think of giving an option to submit timing information
and basic input statistics from the jslint web page? This would let you
collect an aggregate sampling of values to present to the world at large. An
alternate simpler option is just to create a single jslint-of-jslint page
that submits OS, browser and timing information, and provide a link for
people to provide their own statistics for all platforms and browser
versions.

Erik

On Wed, Apr 20, 2011 at 7:48 AM, Douglas Crockford <douglas@...>wrote:

>
>
> http://crockford.com/javascript/performance.html
>
>
>


[Non-text portions of this message have been removed]

This is excellent. I also like Erik's idea to obtain timing information from
users. Browserscope is a really good aggregator and so easy to setup:
http://www.browserscope.org/user/tests/howto

Marcel

On Wed, Apr 20, 2011 at 9:55 AM, Erik Eckhardt <erik@...> wrote:

> That's kind of exciting to see. Chrome's bragging is so justified,
> apparently.
>
> Douglas, what do you think of giving an option to submit timing information
> and basic input statistics from the jslint web page? This would let you
> collect an aggregate sampling of values to present to the world at large.
> An
> alternate simpler option is just to create a single jslint-of-jslint page
> that submits OS, browser and timing information, and provide a link for
> people to provide their own statistics for all platforms and browser
> versions.
>
> Erik
>
> On Wed, Apr 20, 2011 at 7:48 AM, Douglas Crockford <douglas@...
> >wrote:
>
> >
> >
> > http://crockford.com/javascript/performance.html
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Marcel Duran


[Non-text portions of this message have been removed]

Classification: UNCLASSIFIED

> That's kind of exciting to see. Chrome's bragging is so justified,
> apparently.

It is not so simple.  Computation time of JavaScript, and thus metrics of
performance results, is extremely relative.  It is relative to a single machine
with a somewhat static software configuration, the user-agent, and the state of
the user-agent.  In JavaScript performance benchmarks I never see any mention or
measure of user-agent state.  Consider the following:

1) Open Firefox and after all application start up is complete verify the amount
memory consumed by that application process thread, thread hierarchy, or thread
collection is consuming as reported by your respective operating system.

2) Do not open any additional tab in the browser.  In the one default tab go to
JSLint with the "Good Parts" option set and test a very large application, such
the JSLint application itself.  Observed the processing time.

3) Then open 11 additional tabs.  Point some of these tabs to various large PDF
files.  Point one other tab to Facebook and message some people you know and
engage in their live chat for a few seconds.  In yet another tab go to
armorgames.com and play for two minutes in 5 different games.  In yet another
tab go view some of the HTML5 demos online and interact with them.  In yet
another tab go to a website with horrible amounts of advertisements, of which
there are a few to pick from.  Do not close any of these tabs.

4) In the original tab run JSLint again.  The processing time will have
increased by more than 15%, which is outside an allowable threshold of variance.

5) Observe the amount of memory the browser is now consuming compared to when it
was originally opened.  I gotten a single Firefox browser to consume more than
1.4gb of memory on a 2gb machine.  The more memory the browser consumes the
lower its processing performance of JavaScript, especially with regards to large
JavaScript applications receiving extremely large input.

This said you can make Firefox 3.6 out perform Chrome 10 on the same machine
running the same JavaScript application with the same input.  You could even
make IE7 out perform Firefox 3.1 presuming you don't crash the browser or
operating system attempting to push the memory threshold, which Firefox can and
will do on Windows XP.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

On Wed, Apr 20, 2011 at 11:55 AM, Erik Eckhardt <erik@...> wrote:
> That's kind of exciting to see. Chrome's bragging is so justified, apparently.

Am I reading the results wrong? I thought they show that Chrome has
the slowest JavaScript engine.

--
R. Mark Volkmann
Object Computing, Inc.

Ditto that sentiment. It appears that the "Seconds" column shows the number of
seconds, then the last column is relative to IE10, which has the fastest
parser/execution engine. In order of slow to fast:

Chrome, IE 9, Opera 11, FF 4, Safari 5, IE 10

Surprising about Chrome, wonder if it's some RegExp issue.

-Kent.

On Apr 20, 2011, at 3:20 PM, Mark Volkmann wrote:

> On Wed, Apr 20, 2011 at 11:55 AM, Erik Eckhardt <erik@...> wrote:
> > That's kind of exciting to see. Chrome's bragging is so justified,
apparently.
>
> Am I reading the results wrong? I thought they show that Chrome has
> the slowest JavaScript engine.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>



[Non-text portions of this message have been removed]

As the subject line well says, this is the performance of the JavaScript
engine, not the performance of the browser as a whole.  How good is the
interface to the DOM (usually several times slower than the JavaScript
execution on its own) or how many XHR connections to the data servers it
can handle might really make a difference in a whole application.  So,
read these results as what they are, as the subject line states.

Satyam

El 20/04/2011 21:39, Kent Davidson escribió:
> Ditto that sentiment. It appears that the "Seconds" column shows the number of
seconds, then the last column is relative to IE10, which has the fastest
parser/execution engine. In order of slow to fast:
>
> Chrome, IE 9, Opera 11, FF 4, Safari 5, IE 10
>
> Surprising about Chrome, wonder if it's some RegExp issue.
>
> -Kent.
>
> On Apr 20, 2011, at 3:20 PM, Mark Volkmann wrote:
>
>> On Wed, Apr 20, 2011 at 11:55 AM, Erik Eckhardt<erik@...>  wrote:
>>> That's kind of exciting to see. Chrome's bragging is so justified,
apparently.
>> Am I reading the results wrong? I thought they show that Chrome has
>> the slowest JavaScript engine.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1209 / Virus Database: 1500/3585 - Release Date: 04/20/11
>
>

Real life performance measuring almost always involves dom.. not many
computationally expensive things are written for browsers.

I would class jslint as an exception to this. Ie9 has fast javascript
execution but in some cases the same dom performance as ie8 making in the
end, little real world performance benefit. Has anyone tried profiling
Chrome to see what is slow?
On 20 Apr 2011 21:13, "Satyam" <satyam@...> wrote:
> As the subject line well says, this is the performance of the JavaScript
> engine, not the performance of the browser as a whole. How good is the
> interface to the DOM (usually several times slower than the JavaScript
> execution on its own) or how many XHR connections to the data servers it
> can handle might really make a difference in a whole application. So,
> read these results as what they are, as the subject line states.
>
> Satyam
>
> El 20/04/2011 21:39, Kent Davidson escribió:
>> Ditto that sentiment. It appears that the "Seconds" column shows the
number of seconds, then the last column is relative to IE10, which has the
fastest parser/execution engine. In order of slow to fast:
>>
>> Chrome, IE 9, Opera 11, FF 4, Safari 5, IE 10
>>
>> Surprising about Chrome, wonder if it's some RegExp issue.
>>
>> -Kent.
>>
>> On Apr 20, 2011, at 3:20 PM, Mark Volkmann wrote:
>>
>>> On Wed, Apr 20, 2011 at 11:55 AM, Erik Eckhardt<erik@...>
wrote:
>>>> That's kind of exciting to see. Chrome's bragging is so justified,
apparently.
>>> Am I reading the results wrong? I thought they show that Chrome has
>>> the slowest JavaScript engine.
>>>
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1209 / Virus Database: 1500/3585 - Release Date: 04/20/11
>>
>>


[Non-text portions of this message have been removed]

Classification: UNCLASSIFIED
> As the subject line well says, this is the performance of thejava_script
> engine, not the performance of the browser as a whole.

That is a slippery slope.  The depth of integration of the JavaScript
interpreter into the core of the browser application is wildly variant.  As a
result your point is less valid in regards to some user-agents than with others.
Unfortunately, your point cannot be entirely valid unless you wish to suggest a
user-agent that is little more than an API wrapping a JavaScript interpreter,
such as Rhino or Node.js.  With regard to measuring performance and
responsiveness how do you separate the JavaScript interpreter from the browser?
Classification: UNCLASSIFIED

What's the second "IE10" column, is that the performance of IE10 on same
tests as the other browser?  If so, why does its performance vary so
much?

-Eric

On Wed, 20 Apr 2011 15:39:18 -0400
Kent Davidson <kent@...> wrote:

> Ditto that sentiment. It appears that the "Seconds" column shows the
> number of seconds, then the last column is relative to IE10, which
> has the fastest parser/execution engine. In order of slow to fast:
>
> Chrome, IE 9, Opera 11, FF 4, Safari 5, IE 10
>
> Surprising about Chrome, wonder if it's some RegExp issue.
>
> -Kent.
>
> On Apr 20, 2011, at 3:20 PM, Mark Volkmann wrote:
>
> > On Wed, Apr 20, 2011 at 11:55 AM, Erik Eckhardt
> > <erik@...> wrote:
> > > That's kind of exciting to see. Chrome's bragging is so
> > > justified, apparently.
> >
> > Am I reading the results wrong? I thought they show that Chrome has
> > the slowest JavaScript engine.
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >