Group,

I am trying to figure out why slice appears to be slower when executed upon a
large string than merely pointing to a group of indexes.  My presumption is that
slice should be faster, but in my tests it is definitely slower.  Here are some
code examples:

var a, i, x = "some large string of greater than 150kb", y = x.split(''), z =
y.length;
for (i = 0, i < z; i += 1) {
     if (y[i] + y[i + 1].toLowerCase() + y[i + 2].toLowerCase() + y[i +
3].toLowerCase() + y[i + 4].toLowerCase() + y[i + 5].toLowerCase() + y[i +
6].toLowerCase() === "<style") {
         a = "some value";
     }
}
for (i = 0, i < z; i += 1) {
     if (x.slice(i, i + 7) === "<style") {
         a = "some value";
     }
}

The second loop is much easier to read and I presume it would be faster because
it is searching an index of a string, but it is only performing that search once
per iteration of the loop.  The first loop is ugly to look at, but appears
faster in Firefox and Opera, which is surprising because it is performing 7
different look ups into an array per loop iteration.  It is further surprising
considering that large data segments would presumed to be more memory efficient
as a joined string opposed to associating each character with an array index. 
The larger the tested string the more disparaging the results become.

My question is why is the second loop, the pretty one, slower than the first
loop?  Even more strange I have found an exception to this test where the second
loop becomes faster than the first loop only if the value of Z is subject to
change per loop iteration, but the difference of speed in this exception is less
than the difference of speed evident in the stated examples.

Thanks,

Austin
http://prettydiff.com/

For those who haven't seen already:

http://closuretools.blogspot.com/2010/08/introducing-closure-linter.html

http://code.google.com/closure/utilities/docs/linter_howto.html


Marcel

Hi Austin,

It's hard to tell why it's slower/faster without checking the algorithm
implemented for slice on different engines. I did some background research
on implementations of String.indexOf (
http://www.javascriptrules.com/2009/08/12/string-searching-algorithms-in-javascr\
ipt-engines/),
you probably need to do something similar to understand why, unfortunately
you won't be able to check those closed-source engines.

BTW, looking at your example, have you considered regular expression or even
String.indexOf, you could save some time by not splitting a long string into
array.

Regarding your tests, could you share it with the list? Maybe create a new
test suite on http://jsperf.com/


<http://jsperf.com/>Best,

Marcel

On Fri, Sep 3, 2010 at 1:35 PM, Cheney, Edward A SSG RES USAR <
austin.cheney@...> wrote:

>
>
> Group,
>
> I am trying to figure out why slice appears to be slower when executed upon
> a large string than merely pointing to a group of indexes. My presumption is
> that slice should be faster, but in my tests it is definitely slower. Here
> are some code examples:
>
> var a, i, x = "some large string of greater than 150kb", y = x.split(''), z
> = y.length;
> for (i = 0, i < z; i += 1) {
> if (y[i] + y[i + 1].toLowerCase() + y[i + 2].toLowerCase() + y[i +
> 3].toLowerCase() + y[i + 4].toLowerCase() + y[i + 5].toLowerCase() + y[i +
> 6].toLowerCase() === "<style") {
> a = "some value";
> }
> }
> for (i = 0, i < z; i += 1) {
> if (x.slice(i, i + 7) === "<style") {
> a = "some value";
> }
> }
>
> The second loop is much easier to read and I presume it would be faster
> because it is searching an index of a string, but it is only performing that
> search once per iteration of the loop. The first loop is ugly to look at,
> but appears faster in Firefox and Opera, which is surprising because it is
> performing 7 different look ups into an array per loop iteration. It is
> further surprising considering that large data segments would presumed to be
> more memory efficient as a joined string opposed to associating each
> character with an array index. The larger the tested string the more
> disparaging the results become.
>
> My question is why is the second loop, the pretty one, slower than the
> first loop? Even more strange I have found an exception to this test where
> the second loop becomes faster than the first loop only if the value of Z is
> subject to change per loop iteration, but the difference of speed in this
> exception is less than the difference of speed evident in the stated
> examples.
>
> Thanks,
>
> Austin
> http://prettydiff.com/
>
>



--
Marcel Duran


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

Marcel,

I did consider those.  The limitation of indexOf method is that it can only be
used once without altering your source data, and regular expression would
certainly be faster, but there is no native method for using a regular
expression to return a list of indexes.

As far as which tests I was using I was altering the type_define function of the
markup_beauty function to obtain both tests.  I used the it function of the
markupmin function to discover the exception situation.  Both of those scripts
are components of a Pretty Diff tool I maintain at prettydiff.com

http://prettydiff.com/markup_beauty.js
http://prettydiff.com/markupmin.js

Thanks,
Austin

Hello JavaScript enthusiasts,

I'm the organizer of the Strange Loop conference in St. Louis.  This year's
conference will contain a number of interesting JavaScript or web-related talks
including keynotes by Douglas Crockford and Guy Steele.  The conference itself
is a multi-disciplinary conference with many talks on other languages like
Clojure, Scala, Groovy, F#, Lua, Perl, etc, NoSQL talks on MongoDB, Cassandra,
Riak, etc and many other interesting things.  I would encourage you to check out
the full schedule (http://strangeloop2010.com/calendar).  Tickets are $190
through September.

A sampler:
- Guy Steele - How to Think about Parallel Programming: Not!
- Douglas Crockford - Heresy and Heretical Open Source: A Heretic's Perspective
- Ryan Dahl - Parallel Programming with Node.js
- Kyle Simpson - Dude, That's some Strange UI Architecture
- Scott Bale - JavaScript Functions: The Good Parts - Idioms for Encapsulation
and Inheritance
- Justin Love - Classes are Premature Optimization
- Scott Davis - Tomorrow's Tech Today: HTML 5
- Mark Volkmann - jQuery - RIA Miracle!

More info:
Main:  http://strangeloop2010.com
Speakers:  http://strangeloop2010.com/speakers
Schedule:  http://strangeloop2010.com/calendar
Registration:  https://regonline.com/strangeloop2010

It's going to be a fantastic conference and I hope you all can make it.

Thanks,
Alex Miller

What if you use regular expression with String.replace, you have a list of
index plus you can alter the source data. Ex:

var re = /<style/gi,
     str = 'foobar<style foo>foobar</style>foobar<script
bar>foobar</script><STYLE foo>foobar</STYLE>foobar',
     res = str.replace(re, function (match, index, source) {
         print(index); // 6 then 64
         return '*' + match + '*';
     });

print(res); // foobar*<style* foo>foobar</style>foobar<script
bar>foobar</script>*<STYLE* foo>foobar</STYLE>foobar


Best,

Marcel


On Fri, Sep 3, 2010 at 7:55 PM, Cheney, Edward A SSG RES USAR <
austin.cheney@...> wrote:

>
>
> Marcel,
>
> I did consider those. The limitation of indexOf method is that it can only
> be used once without altering your source data, and regular expression would
> certainly be faster, but there is no native method for using a regular
> expression to return a list of indexes.
>
> As far as which tests I was using I was altering the type_define function
> of the markup_beauty function to obtain both tests. I used the it function
> of the markupmin function to discover the exception situation. Both of those
> scripts are components of a Pretty Diff tool I maintain at prettydiff.com
>
> http://prettydiff.com/markup_beauty.js
> http://prettydiff.com/markupmin.js
>
> Thanks,
> Austin
>
>



--
Marcel Duran


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

Marcel,

String replace would certainly be faster, because such instructions pass to the
same code base on which the JavaScript interpreter sits.  String replace does
not provide an index for its global matches so as to allow multiple instructions
to execute on each match or pull each match into an empty array.  In not for
such conditions I would certainly use the replace method.

It should be noted that while it is possible to pass a function with arguments
into the replace method one should never do so.  This essentially creates a
whole through the interpreter to the underling code base.  That means that if
you can inject code into one of the function arguments you can pass that code
through the JavaScript interpreter to possibly compromise the executing
software.  I would gladly sacrifice a measurable amount of performance as a
general best practice to prevent potential code injection.

Thanks,

Austin
http://prettydiff.com/

JSLint now warns about arguments.callee and arguments.caller. These will not be
available in future editions of the language, so it is best to start avoiding
them now.

JSLint doesn't report any error, because "foos" is considered global.

Any suggestion to avoid that error?

Thanks in advance,
Alberto

--------

"use strict";

function foo() {
     var foos;

     foos = 3;
     // ...
     foo = 7; // For a typo I wrote "foo" instead of "foos"

     return foos;
}

foo();
foo(); // getting TypeError

--- In jslint_com@yahoogroups.com, "IceBox" <albertosantini@...> wrote:
>
> JSLint doesn't report any error, because "foos" is considered global.
>

Typo in the typo... :)

I mean "foo" is considered global.

Regards,
Alberto

Icebox,

You cannot avoid having at least one global variable name.  The only way a
variable stops being global is from containment by a function, but at some point
there must be a root function existing at the global level from which the first
layer of scope is provided.

Alluding to an analogy, HTML and XML solve this problem by requiring one single
root element per document, and no more, so that access to the global space
always limited to a single container.

Thanks,
Austin
http://prettydiff.com/

It seems effective to identify if a variable is defined as a function
(either var f = function () {... or function f() {...) or not and whine if
it switches or a function var get set to null.  Or perhaps insure that
variables inside a function don't match the function name.  I realize
there's no classical "types", but it seems to me that a function which
within itself sets itself to null is doing bad things.  Is it practical to
do this within jslint?

The corollary to this is name variables more descriptively such that a typo
won't make it from one valid var to another.

Rob

Rob,

What is the problem if a function changes its method of definition?  I do
understand that there is a difference between the method of declaring a function
with regard to execution versus where the function is defined during procedural
interpretation of the code at the interpreter, but what problems can you
describe where a function morphs during a given scope?  JSLint already complains
if a single variable name is defined more than once in a given scope.  Are you
suggestion it would be helpful for JSLint to always prefer one single format for
declaring a function?  JSLint does not perform flow control and so it cannot
know if there exists some sort of poly morphism in your code, by where a
function dynamically changes form.

What is the problem if a function returns null?  I understand that a bug is
thrown in a function returns null and is executed as part of a mathematical
operation or string concatenation.  You can prevent this easily enough by
ensuring your functions always return a value or an empty string.  JSLint does
not perform flow control and so no matter how grave a problem this may be it is
best fixed proactively and not from validation.

There is no problem with a variable matching the name of its containing
function, because of a difference in namespaces.  The problem that arises is if
the variable in question is not declared within the function, such as a closure,
because then there exists the possibility of a namespace collision.  JSLint
warns about declarations that cause collisions, but you are on your own for
collisions that are the result of reassignment.

" I realize there's no classical "types", but it seems to me that a function
which within itself sets itself to null is doing bad things."
Not necessarily.  A function does not return a value unless it is told to do so.
That is not a bad thing, because not all functions are written to return values.
Some functions may act to alter the value of closures and other may act to
perform operations or extend prototypes.  In these cases the functions are
merely containers of code that are available for reuse, but do not return
values.

I promise that I am not trying to be a stickler or a pain.  I am just trying to
pry some specifics out of you because mentioned several things quickly of which
each are open to interpretation.

"The corollary to this is name variables more descriptively such that a typo
won't make it from one valid var to another."
As I discovered early this spring even well named variables can result in
unintended collisions between nested operations provided enough reuse and
inadequate scope definitions upon where those names are reused.  This is part of
the nature of extended complexity that comes with Lambda programming.

Thanks,
Austin

I think I wasn't adequately clear previously.  If a variable whose value is
a function changes value to a non-function such as number or string or
object, I see this as a concern.  The return value of executing the function
is correctly irrelevant.  My question was given the JSLint codebase, is
adding such a check practical?

For example, I'd love if JSLint flagged that all these cases were invalid:

Case 1:

var somefunc1 = function () {
     somefunc1 = 1; // or null or {} or etc
};

Case 2:

function somefunc2() {
     somefunc2 = 1; // or null or {} or etc
};

Case 3:

someobj.somefunc3 = function () {
     delete someobj.somefunc3;
};


... and aren't lambdas such wonderfully painful and exhilarating things.
Not since pointer arithmetic could we get so cleaver in such elegant and
dangerous ways.  ("Is this an array of pointers or a pointer to an array?")
I so love my career.

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Cheney, Edward A SSG RES USAR
Sent: Friday, September 10, 2010 10:56 AM
To: jslint_com@yahoogroups.com
Subject: Re: RE: [jslint] Collision between global var and function name

Rob,

What is the problem if a function changes its method of definition?  I do
understand that there is a difference between the method of declaring a
function with regard to execution versus where the function is defined
during procedural interpretation of the code at the interpreter, but what
problems can you describe where a function morphs during a given scope?
JSLint already complains if a single variable name is defined more than once
in a given scope.  Are you suggestion it would be helpful for JSLint to
always prefer one single format for declaring a function?  JSLint does not
perform flow control and so it cannot know if there exists some sort of poly
morphism in your code, by where a function dynamically changes form.

What is the problem if a function returns null?  I understand that a bug is
thrown in a function returns null and is executed as part of a mathematical
operation or string concatenation.  You can prevent this easily enough by
ensuring your functions always return a value or an empty string.  JSLint
does not perform flow control and so no matter how grave a problem this may
be it is best fixed proactively and not from validation.

There is no problem with a variable matching the name of its containing
function, because of a difference in namespaces.  The problem that arises is
if the variable in question is not declared within the function, such as a
closure, because then there exists the possibility of a namespace collision.
JSLint warns about declarations that cause collisions, but you are on your
own for collisions that are the result of reassignment.

" I realize there's no classical "types", but it seems to me that a function
which within itself sets itself to null is doing bad things."
Not necessarily.  A function does not return a value unless it is told to do
so.  That is not a bad thing, because not all functions are written to
return values.  Some functions may act to alter the value of closures and
other may act to perform operations or extend prototypes.  In these cases
the functions are merely containers of code that are available for reuse,
but do not return values.

I promise that I am not trying to be a stickler or a pain.  I am just trying
to pry some specifics out of you because mentioned several things quickly of
which each are open to interpretation.

"The corollary to this is name variables more descriptively such that a typo
won't make it from one valid var to another."
As I discovered early this spring even well named variables can result in
unintended collisions between nested operations provided enough reuse and
inadequate scope definitions upon where those names are reused.  This is
part of the nature of extended complexity that comes with Lambda
programming.

Thanks,
Austin

On Thu, Sep 9, 2010 at 3:11 AM, Douglas Crockford <douglas@...> wrote:
> JSLint now warns about arguments.callee and arguments.caller. These will not
be available
> in future editions of the language, so it is best to start avoiding them now.

I don't foresee browser makers removing the functionality, especially
given it's prevalence in libraries that emulate some form of classical
inheritance (run a quick grep through closure and yui3, for instance).

I'd suggest making this change optional, which would allow me to
disable the test for the single file in which I use `callee`/`caller`,
and throw warnings for any other inadvertent uses.

-Mike

Hi all!  I've released an update to my jslint wrapper, jslint4java.  This
release is just a bug fix, plus an update to the latest version of JSLint.

For full details, see what's new:

http://code.google.com/p/jslint4java/#News

Thanks,
-Dom


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

ES5/Strict requires browsers to disable callee and caller. Future editions will
be based on ES5/Strict.

FWIW, here's my $0.02:

Porting style from Conway's PBP, breaking before every operator and using K&R
style indenting makes for very readable JS code IMO.

var fnHello = function (){
   if ( ary_foo.length > 25
     || ary_foo < 5
   ){
     hash_elem.$body
       .find('div .namespace')
       .html( ''
         + '<h3>Hello</h3>
         + '<p>'
           + 'Hello World'
         + '</p>'
       )
       .end()
       .find('input')
       .css({'border-color':'#f00'})
       ;
     hash_state.sw_foo = true;
   }
};

Compare with the alternative:

var fnHello = function (){
   if ( ary_foo.length > 25 ||
     ary_foo < 5
   ){
     hash_elem.
     $body.
     find('div .namespace').
     html('<h3>Hello</h3> +
          '<p>' +
            'Hello World' +
          '</p>').
       end().find('input').
       css({'border-color':'#f00'});
     hash_state.sw_foo = true;
   }
};

Operators on the end make them very hard to spot, not just the ., but also the
|| and the +.

Keeping all lines below 80 characters allows me to view 3 files simultaneously
side-by-side on my monitor.  Finally, all jQuery elements are prefixed by a '$'
sigil, a handy convention.

YMMV.

Cheers, Mike


On Thursday, August 26, 2010 05:57:23 am Douglas Crockford wrote:
> --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
> > > Couldn't it be optional?
> >
> > I would prefer this as well.
> > My colleagues and I made a conscious decision to use a trailing dot to
> > indicate line continuation, which turned out positive in terms of code
> > maintenance.
>
> I made the same decision as well, and I now believe that decision was
> incorrect. I recommend that you update your code.


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

Hi Mark:

On Monday, August 23, 2010 07:27:35 pm you wrote:
> If I understand correctly, in order to get your code to pass JSLint, you
> have to turn off strict whitespace checking.
> If you do that then the following will also be allowed (I hope the extra
> whitespace in my code sample gets retained in the email):
> if (a < 0)
>   {
>            return -1;
>          }
>
> I don't want that to be allowed. I want a single-line if statement to be
> treated as an exception to the strict whitespace rule.

I agree.  That's a cure almost worse than the disease.  So I do turn off strict
white space, as implied in an unrelated jslint response I just posted.

> What do you mean by "syntactically correct". My suggested code is
> syntactically correct, just not JSLint correct.

I had assumed the single-line form is deprecated;  one finds no mention of it
in the w3schools guide:  http://www.w3schools.com/js/js_if_else.asp.  But I'm
willing to admit that might not be the case.

My solution is to turn off white space checking in jslint (which is highly
subjective anyway), and use the single line form as presented below.

As always, YMMV.

Cheers, Mike


> On Mon, Aug 23, 2010 at 5:57 PM, Michael Mikowski
<z_mikowski@...>wrote:
> >  Hi Mark:
> > And what is wrong with the following?
> >
> > ------------
> >
> > function foo(a, b) {
> > if (a < 0){ return -1;}
> > if (a*2 > b){ return 1;}
> >
> > // Now have several lines of code (say less than 10) that do something
> > // complicated with a and b and set the local variable "result".
> >
> > return result;
> > }
> > ---------------
> >
> > It provides all the benefits you mentioned, with the benefit of being
> > syntatically correct.
> >
> > Cheers, Mike
> >
> >
> > ----- Forwarded Message ----
> > From: Mark Volkmann
> > <r.mark.volkmann@...<r.mark.volkmann%40gmail.com>
> >
> > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
> > Sent: Mon, August 23, 2010 1:10:57 PM
> > Subject: Re: [jslint] Re: one line if statements
> >
> > The benefit I see is conciseness of functions without loss of
> > readability. It is fairly common for me to write functions that test
> > parameters and make a determination about whether the rest of the code
> > needs to be executed or whether the result is already known. Here's a
> > simple, contrived example:
> >
> > function foo(a, b) {
> > if (a < 0) return -1;
> > if (a*2 > b) return 1;
> >
> > // Now have several lines of code (say less than 10) that do something
> > // complicated with a and b and set the local variable "result".
> >
> > return result;
> > }
> >
> > This is visually appealing to me. It makes it easy to take in the entire
> > function at a glance and doesn't require scrolling in an editor to see
> > all the code.
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
> > [Non-text portions of this message have been removed]
> >
> > [Non-text portions of this message have been removed]


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

JSLint now considers function statements to produce something that is more const
than var. That means that you will get a warning for attempting change the value
created by a function statement.

So

     function waa() {
         waa = 1;
     }

produces a warning.

JSLint is now doing more checking of strict mode code.

Use of strict mode is highly recommended, but do not use strict mode unless you
fully understand what it does. Strict mode, by design, will break programs.

Do not concatenate strict mode and non-strict mode code together. Doing so can
cause the non-strict code to fail.

I'm new to this list so this may have been answered before but aside from
reading the source code to JSLint (thanks BTW), how do we go about
understanding exactly what strict mode does? The questions on stackoverflow
are kind of mixed and I didn't remember seeing any discussion of this on
jslint.com

SeanK
P.S. I also started programming in JavaScript without learning the language.
I am attempting to fix that now.



*From:* jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] *On
Behalf Of *douglas@...
*Sent:* Thursday, September 16, 2010 1:54 PM
*To:* jslint_com@yahoogroups.com
*Subject:* [jslint] "use strict";





JSLint is now doing more checking of strict mode code.

Use of strict mode is highly recommended, but do not use strict mode unless
you fully understand what it does. Strict mode, by design, will break
programs.

Do not concatenate strict mode and non-strict mode code together. Doing so
can cause the non-strict code to fail.



.




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

Where does the "use strict" declaration go?  Does it go at the top of a
JavaScript file, or at the top of a function, or both, or somewhere else?

Thanks,
Austin

On Fri, Sep 17, 2010 at 8:43 AM, Cheney, Edward A SSG RES USAR <
austin.cheney@...> wrote:

> Where does the "use strict" declaration go?  Does it go at the top of a
> JavaScript file, or at the top of a function, or both, or somewhere else?
>

It must be the very first statement in a file.  I'm sure that jslint will
tell you this. :)

-Dom


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

It may also be at set as the first line of a JavaScript function

so even if the rest of the code (after concatenation or loaded from other
<script> tags) doesn't run in strict mode, the code of this function should

(not sure it will be supported soon)

On Sep 17, 2010, at 10:23 AM, Dominic Mitchell wrote:

> On Fri, Sep 17, 2010 at 8:43 AM, Cheney, Edward A SSG RES USAR <
> austin.cheney@...> wrote:
>
> > Where does the "use strict" declaration go? Does it go at the top of a
> > JavaScript file, or at the top of a function, or both, or somewhere else?
> >
>
> It must be the very first statement in a file. I'm sure that jslint will
> tell you this. :)
>
> -Dom
>
> [Non-text portions of this message have been removed]
>
>



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

Ignoring newcap setting.

acting as always true.

The newcap setting is working correctly in the 2010-09-16 edition that I am
using in Widget Tester.

I download the file from http://www.JSLint.com/jslint.js  .

Harry,

I've also tested the newcap option on the web version at http://www.JSLint.com/ 
.

That is also working correctly.

Harry.

@harry152566,

I'm using the Web version one too and yes I've cleared my cache and newcap is
even when manually set to false.
Just tested it again and I'm getting the same response

Problem at line 432 character 25: A constructor name should start with an
uppercase letter.

and I have

/*jslint white: true, browser: true, devel: true, windows: true, sub: true,
undef: true, newcap: false, nomen: true, eqeqeq: true, plusplus: true, bitwise:
true, regexp: true, immed: true, strict: true */
as my second comment in my file.

If JSLint sees "use strict"; then it turns on option.newcap for you.