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

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

IE very slow when showing/hiding table row

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

Contents

  IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-23 12:23 -0700
    Re: IE very slow when showing/hiding table row Robert Baer <robertbaer@localnet.com> - 2012-03-23 21:00 -0800
      Re: IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-26 09:54 -0700
    Re: IE very slow when showing/hiding table row Gregor Kofler <usenet@gregorkofler.com> - 2012-03-24 10:16 +0100
      Re: IE very slow when showing/hiding table row Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-24 10:58 +0100
      Re: IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-26 09:59 -0700
    Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-24 10:29 +0100
      Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-24 11:56 +0100
      Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-24 12:21 +0100
        Re: IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-26 10:08 -0700
        Re: IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-26 11:30 -0700
          Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-27 17:23 +0200
        Re: IE very slow when showing/hiding table row Gene Wirchenko <genew@ocis.net> - 2012-03-26 13:06 -0700
          Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-27 15:31 +0200
            Re: IE very slow when showing/hiding table row Gene Wirchenko <genew@ocis.net> - 2012-03-27 09:22 -0700
              Re: IE very slow when showing/hiding table row Stefan Weiss <krewecherl@gmail.com> - 2012-03-27 18:58 +0200
                Re: IE very slow when showing/hiding table row Gene Wirchenko <genew@ocis.net> - 2012-03-27 13:39 -0700
                [OT] Octet, byte (was: IE very slow when showing/hiding table row) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-28 21:58 +0200
                  Re: [OT] Octet, byte (was: IE very slow when showing/hiding table row) John G Harris <john@nospam.demon.co.uk> - 2012-03-29 14:40 +0100
              Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-27 19:25 +0200
      Re: IE very slow when showing/hiding table row Lisa Liel <lisa.liel@gmail.com> - 2012-03-26 10:03 -0700
        Re: IE very slow when showing/hiding table row SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-03-27 15:39 +0200
    Re: IE very slow when showing/hiding table row Jeff North <jnorthau@yahoo.com.au> - 2012-03-27 18:47 +1100

Page 1 of 2  [1] 2  Next page →

#13011 — IE very slow when showing/hiding table row

I have an app which requires multiple grouping of data.  Because
nested TBODY tags don't work (you can use them in IE, but hiding a
parent only hides its child rows; it doesn't hide nested TBODYs), I've
had to use something like this:

<table>
<tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
<tr id=row0 style="display:none"><td>
	<table>
	<tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
	<tr id=row1 style="display:none"><td>
		<table>
			[data for group0 and group1]
		</table>
	</td></tr>
	</table>
</td></tr>
<table>

The script is pretty simple:


function doShowHide(rw){
	var o = eval("document.all." + rw);
	if (o.style.display == "none"){
		o.style.display = "";
	} else {
		o.style.display = "none";
	}
}

Easy peasy, right?  But I have a relatively small recordset that ends
up with header indices from 0 to 559.  And when I click a header row,
it takes countable seconds to either show or hide the child row (in
IE, at least, but that's what the customer is using).  Is there some
sort of known memory leak in doing this?  I mean, it's changing one
style attribute on one table row, regardless of how much content it
has (which is never more than maybe 20 rows at the most), and
shouldn't be so sluggish, should it?

If you need to look at it, I made two static examples:

http://starways.net/temp/temp.html (smallish, only 18 indices)
http://starways.net/temp/temp2.html (medium, 559 indices)

Thanks for any help you might be able to offer.
Lisa

[toc] | [next] | [standalone]

#13032

Lisa Liel wrote:
> I have an app which requires multiple grouping of data.  Because
> nested TBODY tags don't work (you can use them in IE, but hiding a
> parent only hides its child rows; it doesn't hide nested TBODYs), I've
> had to use something like this:
>
> <table>
> <tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
> <tr id=row0 style="display:none"><td>
> 	<table>
> 	<tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
> 	<tr id=row1 style="display:none"><td>
> 		<table>
> 			[data for group0 and group1]
> 		</table>
> 	</td></tr>
> 	</table>
> </td></tr>
> <table>
>
> The script is pretty simple:
>
>
> function doShowHide(rw){
> 	var o = eval("document.all." + rw);
> 	if (o.style.display == "none"){
> 		o.style.display = "";
> 	} else {
> 		o.style.display = "none";
> 	}
> }
>
> Easy peasy, right?  But I have a relatively small recordset that ends
> up with header indices from 0 to 559.  And when I click a header row,
> it takes countable seconds to either show or hide the child row (in
> IE, at least, but that's what the customer is using).  Is there some
> sort of known memory leak in doing this?  I mean, it's changing one
> style attribute on one table row, regardless of how much content it
> has (which is never more than maybe 20 rows at the most), and
> shouldn't be so sluggish, should it?
>
> If you need to look at it, I made two static examples:
>
> http://starways.net/temp/temp.html (smallish, only 18 indices)
> http://starways.net/temp/temp2.html (medium, 559 indices)
>
> Thanks for any help you might be able to offer.
> Lisa
   I am a JS dummy - but with deleting code that seemed to do nothing, i 
wound up with the following that does exactly the same thing (note no JS):
<tr id=header0 ><td>Group0</td></tr>
<tr id=row0 style=""><td>
         <table>
         <tr id=header1 ><td>Group1</td></tr>
         <tr id=row1 style=""><td>
                 <table>
                         [data for group0 and group1]
                 </table>
         </td></tr>
         </table>
</td></tr>

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

#13065

On Mar 24, 12:00 am, Robert Baer <robertb...@localnet.com> wrote:
> Lisa Liel wrote:
> > I have an app which requires multiple grouping of data.  Because
> > nested TBODY tags don't work (you can use them in IE, but hiding a
> > parent only hides its child rows; it doesn't hide nested TBODYs), I've
> > had to use something like this:
>
> > <table>
> > <tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
> > <tr id=row0 style="display:none"><td>
> >    <table>
> >    <tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
> >    <tr id=row1 style="display:none"><td>
> >            <table>
> >                    [data for group0 and group1]
> >            </table>
> >    </td></tr>
> >    </table>
> > </td></tr>
> > <table>
>
> > The script is pretty simple:
>
> > function doShowHide(rw){
> >    var o = eval("document.all." + rw);
> >    if (o.style.display == "none"){
> >            o.style.display = "";
> >    } else {
> >            o.style.display = "none";
> >    }
> > }
>
> > Easy peasy, right?  But I have a relatively small recordset that ends
> > up with header indices from 0 to 559.  And when I click a header row,
> > it takes countable seconds to either show or hide the child row (in
> > IE, at least, but that's what the customer is using).  Is there some
> > sort of known memory leak in doing this?  I mean, it's changing one
> > style attribute on one table row, regardless of how much content it
> > has (which is never more than maybe 20 rows at the most), and
> > shouldn't be so sluggish, should it?
>
> > If you need to look at it, I made two static examples:
>
> >http://starways.net/temp/temp.html(smallish, only 18 indices)
> >http://starways.net/temp/temp2.html(medium, 559 indices)
>
> > Thanks for any help you might be able to offer.
> > Lisa
>
>    I am a JS dummy - but with deleting code that seemed to do nothing, i
> wound up with the following that does exactly the same thing (note no JS):
> <tr id=header0 ><td>Group0</td></tr>
> <tr id=row0 style=""><td>
>          <table>
>          <tr id=header1 ><td>Group1</td></tr>
>          <tr id=row1 style=""><td>
>                  <table>
>                          [data for group0 and group1]
>                  </table>
>          </td></tr>
>          </table>
> </td></tr>

It does the same thing, but I want the nested groups to be able to
open and close.  There are going to be a lot of records, and it'll be
easier for the user to see if they start out closed.

Lisa

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

#13033

Am 2012-03-23 20:23, Lisa Liel meinte:
> I have an app which requires multiple grouping of data.  Because
> nested TBODY tags don't work (you can use them in IE, but hiding a
> parent only hides its child rows; it doesn't hide nested TBODYs), I've
> had to use something like this:
> 
> <table>
> <tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
> <tr id=row0 style="display:none"><td>
> 	<table>
> 	<tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
> 	<tr id=row1 style="display:none"><td>
> 		<table>
> 			[data for group0 and group1]
> 		</table>
> 	</td></tr>
> 	</table>
> </td></tr>
> <table>
> 
> The script is pretty simple:
> 
> 
> function doShowHide(rw){
> 	var o = eval("document.all." + rw);
> 	if (o.style.display == "none"){
> 		o.style.display = "";
> 	} else {
> 		o.style.display = "none";
> 	}
> }

Ugh! You know what is said about eval()?

var o = document.getElementById(rw);

will do the same in a safer and compatible way.


> Easy peasy, right?  But I have a relatively small recordset that ends
> up with header indices from 0 to 559.  And when I click a header row,
> it takes countable seconds to either show or hide the child row (in
> IE, at least, but that's what the customer is using).  Is there some
> sort of known memory leak in doing this?  I mean, it's changing one
> style attribute on one table row, regardless of how much content it
> has (which is never more than maybe 20 rows at the most), and
> shouldn't be so sluggish, should it?

It requieres a complete repaint/reflow of the page. *That* is the costly
stuff.

> If you need to look at it, I made two static examples:
> 
> http://starways.net/temp/temp.html (smallish, only 18 indices)
> http://starways.net/temp/temp2.html (medium, 559 indices)

Error in row 5734...

Anyway, speed-wise the expand/collapse works fast enough on my IE7 in a
VM (on a pretty fast computer).

Gregor

-- 
http://vxweb.net

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

#13035

Gregor Kofler wrote:

> Am 2012-03-23 20:23, Lisa Liel meinte:
>> function doShowHide(rw){
>> var o = eval("document.all." + rw);
>> if (o.style.display == "none"){
>> o.style.display = "";
>> } else {
>> o.style.display = "none";
>> }
>> }
> 
> Ugh! You know what is said about eval()?
> 
> var o = document.getElementById(rw);
> 
> will do the same in a safer and compatible way.

ACK for "safer", but I am not so sure about "compatible".  When in doubt, 
use both (with the bracket property accessor instead of eval(), of course), 
falling back to the former (falling back to document.layers, if need be).


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

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

#13066

On Mar 24, 4:16 am, Gregor Kofler <use...@gregorkofler.com> wrote:
> Am 2012-03-23 20:23, Lisa Liel meinte:
>
>
>
> > I have an app which requires multiple grouping of data.  Because
> > nested TBODY tags don't work (you can use them in IE, but hiding a
> > parent only hides its child rows; it doesn't hide nested TBODYs), I've
> > had to use something like this:
>
> > <table>
> > <tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
> > <tr id=row0 style="display:none"><td>
> >    <table>
> >    <tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
> >    <tr id=row1 style="display:none"><td>
> >            <table>
> >                    [data for group0 and group1]
> >            </table>
> >    </td></tr>
> >    </table>
> > </td></tr>
> > <table>
>
> > The script is pretty simple:
>
> > function doShowHide(rw){
> >    var o = eval("document.all." + rw);
> >    if (o.style.display == "none"){
> >            o.style.display = "";
> >    } else {
> >            o.style.display = "none";
> >    }
> > }
>
> Ugh! You know what is said about eval()?
>
> var o = document.getElementById(rw);
>
> will do the same in a safer and compatible way.

I know... I figured it was only once each click and wasn't a big
deal.  But I've changed it.  And compatible doesn't really matter,
because this is an IE only shop, and has been for years and years.

> > Easy peasy, right?  But I have a relatively small recordset that ends
> > up with header indices from 0 to 559.  And when I click a header row,
> > it takes countable seconds to either show or hide the child row (in
> > IE, at least, but that's what the customer is using).  Is there some
> > sort of known memory leak in doing this?  I mean, it's changing one
> > style attribute on one table row, regardless of how much content it
> > has (which is never more than maybe 20 rows at the most), and
> > shouldn't be so sluggish, should it?
>
> It requieres a complete repaint/reflow of the page. *That* is the costly
> stuff.

Huh.  There's not a lot I can do about that, is there.  Unless... if I
were to replace the enclosing rows following each header with an
iframe and pulled up the data in the iframe the first time they
clicked that header... I could still wind up with a lot of iframes,
but there wouldn't be much new to render on the page.  Or maybe I
could simply create an iframe the first time they click the header
row, since it's possible they won't click any but a small number of
them.  Are iframes particularly heavy controls?

>
> > If you need to look at it, I made two static examples:
>
> >http://starways.net/temp/temp.html(smallish, only 18 indices)
> >http://starways.net/temp/temp2.html(medium, 559 indices)
>
> Error in row 5734...

This page lives inside an iframe and reports back to that frame.
Since the example is free floating, it gives a little error when it
tries to report back.  Not relevant.

> Anyway, speed-wise the expand/collapse works fast enough on my IE7 in a
> VM (on a pretty fast computer).

It went pretty fast on mine as well.  And slow as molasses at work.

Thanks,
Lisa

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

#13034

Le 23/03/12 20:23, Lisa Liel a écrit :
> I have an app which requires multiple grouping of data.  Because
> nested TBODY tags don't work (you can use them in IE, but hiding a
> parent only hides its child rows; it doesn't hide nested TBODYs), I've
> had to use something like this:

IE is very very very lazy with table(s) !

it would have to be be faster using visibility than display

> <table>
> <tr id=header0 onclick="doShowHide('row0')"><td>Group0</td></tr>
> <tr id=row0 style="display:none"><td>
> 	<table>
> 	<tr id=header1 onclick="doShowHide('row1')"><td>Group1</td></tr>
> 	<tr id=row1 style="display:none"><td>
> 		<table>
> 			[data for group0 and group1]
> 		</table>
> 	</td></tr>
> 	</table>
> </td></tr>
> <table>
>
> The script is pretty simple:

function doShowHide(rw){
	var o = document.all[rw] || document.getElementById(rw);;
	if (o &&
             o.style) {
		var s = o.style.display;
		o.style.display = s=='none'? '' : 'none;
		}
}



or, maybe ... :

<tr id=header0 onclick="doShowHide(this)"><td>Group0</td></tr>
<tr id=row0 style="display:none">
     <td>
  	<table>

function doShowHide(me){
  me = me.nextSibbling;
  while(me.tagName!='tr') me = me.nextSibbling;
  var s = me.style.display;
  me.style.display = s=='none'? '' : 'none;
}

> If you need to look at it, I made two static examples:
>
> http://starways.net/temp/temp.html (smallish, only 18 indices)
> http://starways.net/temp/temp2.html (medium, 559 indices)

quite long to load, even with Fx (500 ko to download !?)


-- 
Stéphane Moriaux avec/with iMac-intel

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

#13036

Le 24/03/12 10:29, SAM a écrit :
>
> function doShowHide(me){
> me = me.nextSibbling;

nextSibling !

-- 
Stéphane Moriaux avec/with iMac-intel

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

#13037

Le 24/03/12 10:29, SAM a écrit :
> Le 23/03/12 20:23, Lisa Liel a écrit :
>> http://starways.net/temp/temp.html (smallish, only 18 indices)
>> http://starways.net/temp/temp2.html (medium, 559 indices)
>
> quite long to load, even with Fx (500 ko to download !?)

I tried to suppress all useless attributes in tags.

This one is so heavy : <http://cjoint.com/?BCyl5Ob7rsh>

That one is half as heavy : <http://cjoint.com/?BCymmlzp6mB>


-- 
Stéphane Moriaux avec/with iMac-intel

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

#13068

On Mar 24, 6:21 am, SAM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
wrote:
> Le 24/03/12 10:29, SAM a crit :
>
> > Le 23/03/12 20:23, Lisa Liel a crit :
> >>http://starways.net/temp/temp.html(smallish, only 18 indices)
> >>http://starways.net/temp/temp2.html(medium, 559 indices)
>
> > quite long to load, even with Fx (500 ko to download !?)
>
> I tried to suppress all useless attributes in tags.
>
> This one is so heavy : <http://cjoint.com/?BCyl5Ob7rsh>
>
> That one is half as heavy : <http://cjoint.com/?BCymmlzp6mB>

Wow.  That's incredibly trim.  I had no idea that pulling out the
attributes like that would make such a huge difference.  I think I'm
going to be adjusting a *lot* of my web apps.  Thank you so much for
the lesson.

Lisa

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

#13069

On Mar 24, 6:21 am, SAM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
wrote:
> Le 24/03/12 10:29, SAM a crit :
>
> > Le 23/03/12 20:23, Lisa Liel a crit :
> >>http://starways.net/temp/temp.html(smallish, only 18 indices)
> >>http://starways.net/temp/temp2.html(medium, 559 indices)
>
> > quite long to load, even with Fx (500 ko to download !?)
>
> I tried to suppress all useless attributes in tags.
>
> This one is so heavy : <http://cjoint.com/?BCyl5Ob7rsh>
>
> That one is half as heavy : <http://cjoint.com/?BCymmlzp6mB>

May I ask, you included <tbody> tags in your code.  Was that for good
form or is there a reason that would increase the efficiency?

Thanks,
Lisa

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

#13087

Le 26/03/12 20:30, Lisa Liel a écrit :
> On Mar 24, 6:21 am, SAM<stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> wrote:
>>
>> That one is half as heavy :<http://cjoint.com/?BCymmlzp6mB>
>
> May I ask, you included<tbody>  tags in your code.

Oopps ! Sorry ! It's my poor browser Firefox which would have do it ?!
(if it wasn't in your code)

> Was that for good form

good form, more close of DOM

> or is there a reason that would increase the efficiency?

I couldn't say : I haven't IE (M$ does not more produce an IE for Mac)

-- 
Stéphane Moriaux avec/with iMac-intel

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

#13072

On Sat, 24 Mar 2012 12:21:32 +0100, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

>Le 24/03/12 10:29, SAM a écrit :
>> Le 23/03/12 20:23, Lisa Liel a écrit :
>>> http://starways.net/temp/temp.html (smallish, only 18 indices)
>>> http://starways.net/temp/temp2.html (medium, 559 indices)
>>
>> quite long to load, even with Fx (500 ko to download !?)
>
>I tried to suppress all useless attributes in tags.
>
>This one is so heavy : <http://cjoint.com/?BCyl5Ob7rsh>
>
>That one is half as heavy : <http://cjoint.com/?BCymmlzp6mB>

     I must be looking at the wrong thing.  Where is the significant
difference, please?

Sincerely,

Gene Wirchenko

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

#13084

Le 26/03/12 22:06, Gene Wirchenko a écrit :
> On Sat, 24 Mar 2012 12:21:32 +0100, SAM
> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid>  wrote:
>>
>> This one is so heavy :<http://cjoint.com/?BCyl5Ob7rsh>
>>
>> That one is half as heavy :<http://cjoint.com/?BCymmlzp6mB>
>
>       I must be looking at the wrong thing.  Where is the significant
> difference, please?

You have to look at the files in the iframe

1st ) 600 ko (with identation)
2nd ) 300 ko (without any tabulation)

that's the cost of presentation of the html code with imbricated tables



-- 
Stéphane Moriaux avec/with iMac-intel

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

#13088

On Tue, 27 Mar 2012 15:31:13 +0200, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

>Le 26/03/12 22:06, Gene Wirchenko a écrit :
>> On Sat, 24 Mar 2012 12:21:32 +0100, SAM
>> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid>  wrote:
>>>
>>> This one is so heavy :<http://cjoint.com/?BCyl5Ob7rsh>
>>>
>>> That one is half as heavy :<http://cjoint.com/?BCymmlzp6mB>
>>
>>       I must be looking at the wrong thing.  Where is the significant
>> difference, please?
>
>You have to look at the files in the iframe
>
>1st ) 600 ko (with identation)
>2nd ) 300 ko (without any tabulation)
>
>that's the cost of presentation of the html code with imbricated tables

     No, what is the significant difference in *code*, please, that
makes the difference?

     (I am still learning JavaScript and often stumble often
unfamiliar or unusual uses.)

Sincerely,

Gene Wirchenko

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

#13091

On 2012-03-27 18:22, Gene Wirchenko wrote:
> On Tue, 27 Mar 2012 15:31:13 +0200, SAM
> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
>>Le 26/03/12 22:06, Gene Wirchenko a écrit :
>>> On Sat, 24 Mar 2012 12:21:32 +0100, SAM
>>> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid>  wrote:
>>>>
>>>> This one is so heavy :<http://cjoint.com/?BCyl5Ob7rsh>
>>>>
>>>> That one is half as heavy :<http://cjoint.com/?BCymmlzp6mB>
>>>
>>>       I must be looking at the wrong thing.  Where is the significant
>>> difference, please?
>>
>>You have to look at the files in the iframe
>>
>>1st ) 600 ko (with identation)
>>2nd ) 300 ko (without any tabulation)
>>
>>that's the cost of presentation of the html code with imbricated tables
> 
>      No, what is the significant difference in *code*, please, that
> makes the difference?

As far as I can see, there's no significant difference at all. The
second example just has some extra whitespace removed. That the
whitespace accounts for over half of the document size is a bit extreme,
but not unheard of. The JS code is unchanged.

(BTW, "ko" is short for kilo-octet, which is French for kilobyte)

- stefan

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

#13096

On Tue, 27 Mar 2012 18:58:57 +0200, Stefan Weiss
<krewecherl@gmail.com> wrote:

>On 2012-03-27 18:22, Gene Wirchenko wrote:

[snip]

>>      No, what is the significant difference in *code*, please, that
>> makes the difference?
>
>As far as I can see, there's no significant difference at all. The
>second example just has some extra whitespace removed. That the
>whitespace accounts for over half of the document size is a bit extreme,
>but not unheard of. The JS code is unchanged.

     Ah, thank you.

[snip]

Sincerely,

Gene Wirchenko

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

#13105 — [OT] Octet, byte (was: IE very slow when showing/hiding table row)

Stefan Weiss wrote:

> On 2012-03-27 18:22, Gene Wirchenko wrote:
>> On Tue, 27 Mar 2012 15:31:13 +0200, SAM
>> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
>>> 1st ) 600 ko (with identation)
>>> 2nd ) 300 ko (without any tabulation)
>> […]
> […]
> (BTW, "ko" is short for kilo-octet, which is French for kilobyte)

"Kilo-octet" is not only French, but it is using the exact (but outside of 
French unusual) multiple of the unit of 8-bit based data storage.  The unit 
symbols `o', and `ko', are AFAIK not used outside of French texts, though. 

Also, `kilobyte' is the colloquial but non-standard term for "1024 bytes"; 
the standard and correct expression, per IEC 60027-2 (1999), for 1024 bytes 
is 1 kibibyte (kilo-binary byte; abbreviation: KiB), as one SI kilobyte 
(1 kB) would consist of 1000 bytes (the latter is usually used by 
manufacturers of storage devices, leaving less computer-savvy users to 
wonder where the "remaining space" on the disk went).  See also [1].

"Byte" is more common than "octet" for 8 bits of data because few if any 
contemporary computer systems or storage devices use bytes that do not 
consist of 8 bits [2].  However, for exactness, the term "octet" is used 
e.g. in RFCs (in English language), for example in RFC 4515 "Lightweight 
Directory Access Protocol (LDAP): String Representation of Search Filters" 
(2006) [3].


PointedEars
___________
[1] <http://en.wikipedia.org/wiki/Binary_prefix>
[2] cf. <http://en.wikipedia.org/wiki/Byte>
[3] <http://tools.ietf.org/html/rfc4515>
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

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

#13111 — Re: [OT] Octet, byte (was: IE very slow when showing/hiding table row)

On Wed, 28 Mar 2012 at 21:58:45, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

  <snip>
>Also, `kilobyte' is the colloquial but non-standard term for "1024 bytes";

It is also the correct SI term for that number of bytes +/- 3%, a fact
that the programmers of the 1960s and later have conspicuously failed to
understand.


>the standard and correct expression, per IEC 60027-2 (1999), for 1024 bytes
>is 1 kibibyte (kilo-binary byte; abbreviation: KiB),

Actually, it is just *one* of the correct expressions.

1024 is also correct, and the one that is least likely to be
misunderstood.


> as one SI kilobyte
>(1 kB) would consist of 1000 bytes (the latter is usually used by
>manufacturers of storage devices, leaving less computer-savvy users to
>wonder where the "remaining space" on the disk went).  See also [1].
  <snip>

If you see a purchase contract containing the specification for a
storage device you would expect to see
  "All measurements are in SI units, traceable to a national standard",
but of course no professional programmer would admit to knowing what
'SI' is as it wasn't invented by a programmer.

The less savvy users also forget about the operating system's overheads.
These can take several percent of the available space.


  John
-- 
John Harris

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

#13092

Le 27/03/12 18:22, Gene Wirchenko a écrit :
> On Tue, 27 Mar 2012 15:31:13 +0200, SAM
> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid>  wrote:
>
>> Le 26/03/12 22:06, Gene Wirchenko a écrit :
>>> On Sat, 24 Mar 2012 12:21:32 +0100, SAM
>>> <stephanemoriaux.NoAdmin@wanadoo.fr.invalid>   wrote:
>>>>
>>>> This one is so heavy :<http://cjoint.com/?BCyl5Ob7rsh>
>>>>
>>>> That one is half as heavy :<http://cjoint.com/?BCymmlzp6mB>
>>>
>>>        I must be looking at the wrong thing.  Where is the significant
>>> difference, please?
>>
>> You have to look at the files in the iframe
>>
>> 1st ) 600 ko (with identation)
>> 2nd ) 300 ko (without any tabulation)
>>
>> that's the cost of presentation of the html code with imbricated tables
>
>       No, what is the significant difference in *code*, please, that
> makes the difference?

not understood
difference about what ?

The html, css an javascript codes are exactly the same.
Just in the 2nd example all useless spaces are removed.
(it rests to remove the control-carriages too)


>       (I am still learning JavaScript and often stumble often
> unfamiliar or unusual uses.)

as these examples are on the OP's model,
here we haven't the image-buttons [+][-] but their attribute alt (button 
to show/hide content) that have to be pressed

-- 
Stéphane Moriaux avec/with iMac-intel

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web