Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #13879 > unrolled thread

Modify Element Tag Question

Back to article view | Back to comp.lang.javascript

Contents

  Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-11 13:42 -0600
    Re: Modify Element Tag Question Martin Honnen <mahotrash@yahoo.de> - 2012-05-12 12:00 +0200
      Re: Modify Element Tag Question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 15:02 +0200
        Re: Modify Element Tag Question John G Harris <john@nospam.demon.co.uk> - 2012-05-12 16:15 +0100
          Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-12 14:32 -0600
    Re: Modify Element Tag Question Dr J R Stockton <reply1219@merlyn.demon.co.uk.not.invalid> - 2012-05-12 19:29 +0100
      Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-12 18:08 -0600
        Re: Modify Element Tag Question "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-13 08:11 +0000
      Re: Modify Element Tag Question Martin Honnen <mahotrash@yahoo.de> - 2012-05-13 11:25 +0200
        Re: Modify Element Tag Question Dr J R Stockton <reply1220@merlyn.demon.co.uk.not.invalid> - 2012-05-14 20:19 +0100
    Re: Modify Element Tag Question Denis McMahon <denismfmcmahon@gmail.com> - 2012-05-13 02:59 +0000
      Re: Modify Element Tag Question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-13 15:50 +0200
        Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-13 08:56 -0600
        Re: Modify Element Tag Question Dr J R Stockton <reply1219@merlyn.demon.co.uk.not.invalid> - 2012-05-14 20:01 +0100
      Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-13 09:00 -0600
        Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-14 08:45 -0600
          Re: Modify Element Tag Question Scott Sauyet <scott.sauyet@gmail.com> - 2012-05-14 16:31 -0700
            Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-15 09:03 -0600
          Re: Modify Element Tag Question Dr J R Stockton <reply1220@merlyn.demon.co.uk.not.invalid> - 2012-05-15 20:04 +0100
            Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-15 22:19 -0600
              Re: Modify Element Tag Question Dr J R Stockton <reply1220@merlyn.demon.co.uk.not.invalid> - 2012-05-17 19:13 +0100
                Re: Modify Element Tag Question Scott Sauyet <scott.sauyet@gmail.com> - 2012-05-17 18:48 -0700
                  Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-18 13:14 -0600
                  Re: Modify Element Tag Question Dr J R Stockton <reply1220@merlyn.demon.co.uk.not.invalid> - 2012-05-19 20:47 +0100
                    Re: Modify Element Tag Question "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-20 08:31 +0000
                      Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-20 18:25 -0600
                        Re: Modify Element Tag Question "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-21 16:06 +0000
                          Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-21 13:24 -0600
                            Re: Modify Element Tag Question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-05-21 13:34 -0600
                              Re: Modify Element Tag Question Scott Sauyet <scott.sauyet@gmail.com> - 2012-05-21 13:09 -0700
                      Re: Modify Element Tag Question Dr J R Stockton <reply1221@merlyn.demon.co.uk.not.invalid> - 2012-05-21 20:33 +0100

Page 2 of 2 — ← Prev page 1 [2]

#14034

In comp.lang.javascript message <a1go68F87fU1@mid.individual.net>, Tue,
15 May 2012 22:19:14, Mel Smith <med_cutout_syntel@aol.com> posted:

>
>    Scott Sauyet said this morning that running *my* page on *his* machine
>took less than a second ????
>
>    I'll look into why *my* clicking on one of the Sort buttons took nearly
>4 secs to complete the sort, and then bold the new sort key. Hmmmm ...

If you've not yet succeeded, post the sort algorithm, and the structure
of the elements which it sorts, and the comparison function.

But I don't recall what browsers you and Scott Sauyet are using.  That
can make a very considerable difference.

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [next] | [standalone]

#14036

Dr J R Stockton wrote:
> Mel Smith wrote:

>>    Scott Sauyet said this morning that running *my* page on *his* machine
>>took less than a second ????
>
>> I'll look into why *my* clicking on one of the Sort buttons took nearly
>> 4 secs to complete the sort, and then bold the new sort key. Hmmmm ...

AISB, the biggest issue is almost certainly the way the content is
loaded one bit a time back into the table.

I tested the page Mel emailed me on my WinXP machine (dual 2.5 GHz
processors, 3GB RAM) on recent versions of Chrome, Firefox, Safari,
and Opera, as well as IE8, IE6, and IE5.01.  On IE6 and IE8, the sort/
rebuild process took about 1.5 seconds.  On all the others, it was
well below half a second.

I didn't bother loading up my Linux partition; it's generally just a
little faster than the Windows one at tasks like this.

> If you've not yet succeeded, post the sort algorithm, and the structure
> of the elements which it sorts, and the comparison function.

The page Mel supplied included a fair bit of sensitive customer data,
which, I assume is why he hasn't posted simpler versions anywhere.
But there is nothing sensitive about the sorting routines, and they
are simple and appropriate:


    function cmpNameAsc(x, y) {
      if (x.mem === y.mem) return 0;
      return (x.mem > y.mem) ? 1 : -1;
    }

    // ... elsewhere ...

    allData.sort(cmpNameAsc);

The members of the array `allData` are fairly simple objects created
from a constructor function.  Their fields are scraped at startup from
a fairly large table.  But the actual sort is a standard array sort.
I've never looked, but I assume that the standard sort is either a
mergesort or a quicksort.  In either case, the sort is almost
certainly not the culprit.

But after that sort, the table is updated by individually setting the
innerHTML on each cell.  I'm guessing that most of the time Mel is
seeing is in that process.


> But I don't recall what browsers you and Scott Sauyet are using.  That
> can make a very considerable difference.

I can't imagine what's causing the difference unless it's simply the
raw power of the machines.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#14037

Scott said:

AISB, the biggest issue is almost certainly the way the content is
loaded one bit a time back into the table.

I tested the page Mel emailed me on my WinXP machine (dual 2.5 GHz
processors, 3GB RAM) on recent versions of Chrome, Firefox, Safari,
and Opera, as well as IE8, IE6, and IE5.01.  On IE6 and IE8, the sort/
rebuild process took about 1.5 seconds.  On all the others, it was
well below half a second.

    I (Mel) tested on my IE7 browser, and *my error*:  my time was approx 
*2.5 seconds*  (Not 4 secs) from:  Clivking the 'Sort' Button thru the 
following sequences:

        a.    Unbolding the 'previous' bolded fields
        b.    Sorting the data fields on the new sort key
        c.    Rebuilding the table
        d.    Bolding the new bold sort fields
        e.    Informing the user of the new Sort Field


I didn't bother loading up my Linux partition; it's generally just a
little faster than the Windows one at tasks like this.

> If you've not yet succeeded, post the sort algorithm, and the structure
> of the elements which it sorts, and the comparison function.

Dr J:
    Yes, it works fine now !


The page Mel supplied included a fair bit of sensitive customer data,
which, I assume is why he hasn't posted simpler versions anywhere.
But there is nothing sensitive about the sorting routines, and they
are simple and appropriate:

Scott:
    Yes, because I have personal info on 613 residences, I feel obliged to 
restrict access to the internal data


    function cmpNameAsc(x, y) {
      if (x.mem === y.mem) return 0;
      return (x.mem > y.mem) ? 1 : -1;
    }

    // ... elsewhere ...

    allData.sort(cmpNameAsc);

The members of the array `allData` are fairly simple objects created
from a constructor function.  Their fields are scraped at startup from
a fairly large table.  But the actual sort is a standard array sort.
I've never looked, but I assume that the standard sort is either a
mergesort or a quicksort.  In either case, the sort is almost
certainly not the culprit.

But after that sort, the table is updated by individually setting the
innerHTML on each cell.  I'm guessing that most of the time Mel is
seeing is in that process.


> But I don't recall what browsers you and Scott Sauyet are using. That
> can make a very considerable difference.


I can't imagine what's causing the difference unless it's simply the
raw power of the machines.


Scott:

    Did another test:
    Chrome 19.0.1084.46 took less than a second !
    FireFox 12.0 took approx 1.5 seconds.
    IE7 took approx 2 seconds

Sorry to have led you astray.

--Mel

[toc] | [prev] | [next] | [standalone]

#14041

In comp.lang.javascript message <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g
2000vbx.googlegroups.com>, Thu, 17 May 2012 18:48:05, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>The page Mel supplied included a fair bit of sensitive customer data,
>which, I assume is why he hasn't posted simpler versions anywhere.
>But there is nothing sensitive about the sorting routines, and they
>are simple and appropriate:
>
>    function cmpNameAsc(x, y) {
>      if (x.mem === y.mem) return 0;
>      return (x.mem > y.mem) ? 1 : -1;
>    }

I think, supported by very brief testing, that it would be better to do
a > test and return +1, else do a < test and return -1; else return 0.
That is on the assumption that equality is rare.

The code shown will almost half of the time do one comparison, whereas
comparing first with 0 will almost always do two comparisons.

The difference made to the overall time will be small but possibly
measurable; and it may be browser-dependent.

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike 6.05  WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#14044

Dr J R Stockton wrote on 19 mei 2012 in comp.lang.javascript:

> In comp.lang.javascript message
> <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g 2000vbx.googlegroups.com>,
> Thu, 17 May 2012 18:48:05, Scott Sauyet <scott.sauyet@gmail.com>
> posted: 
> 
>>The page Mel supplied included a fair bit of sensitive customer data,
>>which, I assume is why he hasn't posted simpler versions anywhere.
>>But there is nothing sensitive about the sorting routines, and they
>>are simple and appropriate:
>>
>>    function cmpNameAsc(x, y) {
>>      if (x.mem === y.mem) return 0;
>>      return (x.mem > y.mem) ? 1 : -1;
>>    }

No reason for prohibiting typeconversion with ===,
or is this a speed issue?

if the === false and the == is true, 
you would end up with returning -1,
not so useful.

> I think, supported by very brief testing, that it would be better to
> do 
>a > test and return +1, else do a < test and return -1; else return 0.
> That is on the assumption that equality is rare.
> 
> The code shown will almost half of the time do one comparison, whereas
> comparing first with 0 will almost always do two comparisons.
> 
> The difference made to the overall time will be small but possibly
> measurable; and it may be browser-dependent.


function cmpNameAsc(x, y) {
     return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
};

This way it looks nicer to me,
would it be even faster?


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#14047

Evertjan said:

>
> function cmpNameAsc(x, y) {
>     return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
> };
>
> This way it looks nicer to me,
> would it be even faster?

I'll give it a try tomorrow.

Thank you.

-Mel Smith

[toc] | [prev] | [next] | [standalone]

#14053

Mel Smith wrote on 21 mei 2012 in comp.lang.javascript:

> Evertjan said:
> 
>>
>> function cmpNameAsc(x, y) {
>>     return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>> };
>>
>> This way it looks nicer to me,
>> would it be even faster?
> 
> I'll give it a try tomorrow.

missed a "?", try:


return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;




-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#14062

Evertjan said:
>>> function cmpNameAsc(x, y) {
>>>     return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>>> };
>>>
>>> This way it looks nicer to me,
>>> would it be even faster?
>>
>> I'll give it a try tomorrow.
>
> missed a "?", try:
>
>
> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
>


Hi Evertjan:

    Yes, I tried it last nite and it didn't work, so I didn't fiddle with 
it.  Will try it again later.

Thanks,

-Mel

[toc] | [prev] | [next] | [standalone]

#14063

Evertjan said:

>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
>>
>
>

Evertjan:

    Using the corrected version above, it seems that the speed is about the 
same -- maybe a tad slower ? (just an eyeball test though), and my *real* 
user is active now in Arizona, so I'd better wait for the evening to try it 
again.

Thanks,

-Mel Smith

[toc] | [prev] | [next] | [standalone]

#14065

Mel Smith wrote:
> Evertjan said:
>
>>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
> Using the corrected version above, it seems that the speed is about the
> same -- maybe a tad slower ? (just an eyeball test though), and my *real*
> user is active now in Arizona, so I'd better wait for the evening to try it
> again.

That would be a micro-optimization.  It might be worth doing.  But
it's not likely to significantly change any of your speed.

I did a JSPerf test, and the results of three tests each on these four
browsers of sorting arrays of 1000 random numbers were (in operations
per second, so higher is better):

    Android 2.3.4:  equals first: 114, equals last: 121
    Chrome 19.0: equals first: 2259, equals last: 2370
    Firefox 10.0: equals first: 3191, equals last: 3410
    IE 8.0: equals first: 131, equals last: 131

<http://jsperf.com/sort-test-order>

There's up to a 7% difference; it's probably a good idea in general to
choose the faster version.  But it almost certainly won't be
noticeable for your case.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#14066

In comp.lang.javascript message <XnsA0596AFCC343Eeejj99@194.109.133.133>
, Sun, 20 May 2012 08:31:04, Evertjan. <exjxw.hannivoort@interxnl.net>
posted:

>Dr J R Stockton wrote on 19 mei 2012 in comp.lang.javascript:
>
>> In comp.lang.javascript message
>> <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g 2000vbx.googlegroups.com>,
>> Thu, 17 May 2012 18:48:05, Scott Sauyet <scott.sauyet@gmail.com>
>> posted:
>>
>>>The page Mel supplied included a fair bit of sensitive customer data,
>>>which, I assume is why he hasn't posted simpler versions anywhere.
>>>But there is nothing sensitive about the sorting routines, and they
>>>are simple and appropriate:
>>>
>>>    function cmpNameAsc(x, y) {
>>>      if (x.mem === y.mem) return 0;
>>>      return (x.mem > y.mem) ? 1 : -1;
>>>    }
>
>No reason for prohibiting typeconversion with ===,
>or is this a speed issue?
>
>if the === false and the == is true,
>you would end up with returning -1,
>not so useful.

In using a sort routine for a comparison function, it seems to me rather
probable that the two arguments will be of the same type.  One could of
course construct an artificial counter-example.


>> I think, supported by very brief testing, that it would be better to
>> do
>>a > test and return +1, else do a < test and return -1; else return 0.
>> That is on the assumption that equality is rare.
>>
>> The code shown will almost half of the time do one comparison, whereas
>> comparing first with 0 will almost always do two comparisons.
>>
>> The difference made to the overall time will be small but possibly
>> measurable; and it may be browser-dependent.
>
>
>function cmpNameAsc(x, y) {
>     return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>};
>
>This way it looks nicer to me,
>would it be even faster?

No.  At least, not in FF12, in a crude test.  But the OP should try that
properly.

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web