thr3ads.net - Rails spinoffs - $$ is slooooow in IE [May 2007]

If this information is useful, please help other people find it:
Share via:

altay-6c8tSettBfPPIjl8wruziA@public.gmane.org

2007-May-28 03:05 UTC

$$ is slooooow in IE

While $$ and getElementsByClassName are ridiculously speedy in Firefox
(thanks to XPath), I''m finding both functions to be intolerably slow
in IE.  The page I''m working with has fewer than 1000 elements --
doesn''t seem THAT big -- and it''s still taking upwards of 4
seconds
(!) to pick out the right ones.

Are there documented problems with particular versions/builds of IE?
(Perhaps I''m just unlucky enough to be testing on one of those
builds.)

Those functions are so damn convenient in theory, but are causing me a
lot of headaches in practice.  How do you all deal with this issue?
Am I missing something obvious here?

Thanks,
Altay


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Tom Gregory

2007-May-28 03:54 UTC

head link

Re: $$ is slooooow in IE

What steps have you taken to optimize your query?  Have you  
experimented with different ways to return the same result?

Show us your query, and describe your page.


TAG

On May 27, 2007, at 9:05 PM, altay-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
>
> While $$ and getElementsByClassName are ridiculously speedy in Firefox
> (thanks to XPath), I''m finding both functions to be intolerably
slow
> in IE.  The page I''m working with has fewer than 1000 elements --
> doesn''t seem THAT big -- and it''s still taking upwards of
4 seconds
> (!) to pick out the right ones.
>
> Are there documented problems with particular versions/builds of IE?
> (Perhaps I''m just unlucky enough to be testing on one of those
> builds.)
>
> Those functions are so damn convenient in theory, but are causing me a
> lot of headaches in practice.  How do you all deal with this issue?
> Am I missing something obvious here?
>
> Thanks,
> Altay
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

altay-6c8tSettBfPPIjl8wruziA@public.gmane.org

2007-May-28 16:24 UTC

head link

Re: $$ is slooooow in IE

Hi TAG-

Thanks for the reply.

Here what''s up.  I''ve got an arbitrary number of divs, with
class=''qedit'', and id=''{uniqueid}_qedit''. 
The user can click on an
"edit" link to open up a qedit div for editing, but s/he can only edit
one at a time.  In other words, when you click ''edit,'' it
should find
and close any currently-open divs, and open the div you clicked on.

Hm, now that I actually write out my requirements, I suppose I could
simply store the currently-open id in a global, which would be a
little more straightforward.  Doh.  It''s time to refactor.

But, for the sake of discussion -- and cause I''ve run into this issue
in other situations -- here''s my original implementation:

function toggle_qedit( prefix ) {
  var t0 = new Date();

  var all_qedits = $$(''.qedit'');
  //var all_qedits = document.getElementsByClassName(''qedit'');
  //var all_qedits = $$(''div.qedit'');
  //var all_qedits = find_elts_by_class( ''div'',
''qedit'' );

  var t1 = new Date();
  $(''debug'').innerHTML = "It took " +
(t1.getTime()-t0.getTime()) +
"ms to do that.";

  all_qedits.each( function(q) {
    var qid = q.id.split(''_'')[0];
    if ( qid == prefix && q.style.display == ''none'' )
{
      div_toggle( qid, true );
    }
    else {
      div_toggle( qid, false );
    }
  });
}

It loops through all the divs with class="qedit", and hides each of
them unless it matches the div you clicked.

There are 15 of these divs on my test page.

For optimization, you can see that I tried four ways to get the
elements:
- $$(''.qedit'')
- document.getElementsByClassName(''qedit'')
- $$(''div.qedit'')
- find_elts_by_class( ''div'', ''qedit'') 
--> my own custom function,
which is not DOM-specific*

Anything else I should try?

Here''s the breakdown:

4172ms -- $$(''.qedit'')
3797ms -- document.getElementsByClassName
266ms   -- $$(''div.qedit'')
16ms     -- my custom function

So clearly, looking for div.qedit instead of just .qedit helped a lot,
but it was still trumped by my non-prototype solution.  I don''t get
it.  Do you see any glaring errors in my implementation of $$?

Altay

*  FYI, here''s my custom function:

function find_elts_by_class( tagname, classname ) {
  var target_elts = [];
  if (Prototype.BrowserFeatures.XPath ) {
    target_elts = $$( tagname + ''.'' + classname );
  }
  else {
    var elts = document.getElementsByTagName( tagname );
    for (var i=0;i<elts.length;i++) {
      if (elts[i].className == classname) {
        target_elts.push( elts[i] );
      }
    }
  }
  return target_elts;
}



On May 27, 11:54 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org>
wrote:> What steps have you taken to optimize your query?  Have you  
> experimented with different ways to return the same result?
>
> Show us your query, and describe your page.
>
> TAG
>
> On May 27, 2007, at 9:05 PM, a...-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
>
>
>
>
>
> > While $$ and getElementsByClassName are ridiculously speedy in Firefox
> > (thanks to XPath), I''m finding both functions to be
intolerably slow
> > in IE.  The page I''m working with has fewer than 1000
elements --
> > doesn''t seem THAT big -- and it''s still taking
upwards of 4 seconds
> > (!) to pick out the right ones.
>
> > Are there documented problems with particular versions/builds of IE?
> > (Perhaps I''m just unlucky enough to be testing on one of
those
> > builds.)
>
> > Those functions are so damn convenient in theory, but are causing me a
> > lot of headaches in practice.  How do you all deal with this issue?
> > Am I missing something obvious here?
>
> > Thanks,
> > Altay- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

altay-6c8tSettBfPPIjl8wruziA@public.gmane.org

2007-May-28 16:42 UTC

head link

Re: $$ is slooooow in IE

Aha, if I change my custom function to use Element.hasClassName(elt,
''myclass'') instead of
elt.className==''myclass'' , then it jumps from
16ms to ~250ms.  This matches $$(''div.blah''), which also took
~250ms.

So, FWIW, if you don''t need Element.hasClassName -- that is,
you''re
only dealing with a single class -- it looks like you can score an
order of magnitude speed improvement by using "if
elt.className==''myclass''" instead.

Whoa!  Hold on... even elt.className.match(''myclass'') is way
faster
(16ms) than hasClassName.  And that takes care of the multiple-
classname issue, right?

Has anyone done any detailed profiling of hasClassName?  Looks like
improvements in that might speed up IE''s $$ significantly.

Altay



On May 28, 12:24 pm, "a...-6c8tSettBfPPIjl8wruziA@public.gmane.org"
<a...-6c8tSettBfPPIjl8wruziA@public.gmane.org>
wrote:> Hi TAG-
>
> Thanks for the reply.
>
> Here what''s up.  I''ve got an arbitrary number of divs,
with
> class=''qedit'', and
id=''{uniqueid}_qedit''.  The user can click on an
> "edit" link to open up a qedit div for editing, but s/he can only
edit
> one at a time.  In other words, when you click ''edit,'' it
should find
> and close any currently-open divs, and open the div you clicked on.
>
> Hm, now that I actually write out my requirements, I suppose I could
> simply store the currently-open id in a global, which would be a
> little more straightforward.  Doh.  It''s time to refactor.
>
> But, for the sake of discussion -- and cause I''ve run into this
issue
> in other situations -- here''s my original implementation:
>
> function toggle_qedit( prefix ) {
>   var t0 = new Date();
>
>   var all_qedits = $$(''.qedit'');
>   //var all_qedits =
document.getElementsByClassName(''qedit'');
>   //var all_qedits = $$(''div.qedit'');
>   //var all_qedits = find_elts_by_class( ''div'',
''qedit'' );
>
>   var t1 = new Date();
>   $(''debug'').innerHTML = "It took " +
(t1.getTime()-t0.getTime()) +
> "ms to do that.";
>
>   all_qedits.each( function(q) {
>     var qid = q.id.split(''_'')[0];
>     if ( qid == prefix && q.style.display ==
''none'' ) {
>       div_toggle( qid, true );
>     }
>     else {
>       div_toggle( qid, false );
>     }
>   });
>
> }
>
> It loops through all the divs with class="qedit", and hides each
of
> them unless it matches the div you clicked.
>
> There are 15 of these divs on my test page.
>
> For optimization, you can see that I tried four ways to get the
> elements:
> - $$(''.qedit'')
> - document.getElementsByClassName(''qedit'')
> - $$(''div.qedit'')
> - find_elts_by_class( ''div'', ''qedit'') 
--> my own custom function,
> which is not DOM-specific*
>
> Anything else I should try?
>
> Here''s the breakdown:
>
> 4172ms -- $$(''.qedit'')
> 3797ms -- document.getElementsByClassName
> 266ms   -- $$(''div.qedit'')
> 16ms     -- my custom function
>
> So clearly, looking for div.qedit instead of just .qedit helped a lot,
> but it was still trumped by my non-prototype solution.  I don''t
get
> it.  Do you see any glaring errors in my implementation of $$?
>
> Altay
>
> *  FYI, here''s my custom function:
>
> function find_elts_by_class( tagname, classname ) {
>   var target_elts = [];
>   if (Prototype.BrowserFeatures.XPath ) {
>     target_elts = $$( tagname + ''.'' + classname );
>   }
>   else {
>     var elts = document.getElementsByTagName( tagname );
>     for (var i=0;i<elts.length;i++) {
>       if (elts[i].className == classname) {
>         target_elts.push( elts[i] );
>       }
>     }
>   }
>   return target_elts;
>
> }
>
> On May 27, 11:54 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org>
wrote:
>
>
>
> > What steps have you taken to optimize your query?  Have you  
> > experimented with different ways to return the same result?
>
> > Show us your query, and describe your page.
>
> > TAG
>
> > On May 27, 2007, at 9:05 PM,
a...-6c8tSettBfPPIjl8wruziA@public.gmane.org wrote:
>
> > > While $$ and getElementsByClassName are ridiculously speedy in
Firefox
> > > (thanks to XPath), I''m finding both functions to be
intolerably slow
> > > in IE.  The page I''m working with has fewer than 1000
elements --
> > > doesn''t seem THAT big -- and it''s still taking
upwards of 4 seconds
> > > (!) to pick out the right ones.
>
> > > Are there documented problems with particular versions/builds of
IE?
> > > (Perhaps I''m just unlucky enough to be testing on one of
those
> > > builds.)
>
> > > Those functions are so damn convenient in theory, but are causing
me a
> > > lot of headaches in practice.  How do you all deal with this
issue?
> > > Am I missing something obvious here?
>
> > > Thanks,
> > > Altay- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Tom Gregory

2007-May-28 18:34 UTC

head link

Re: $$ is slooooow in IE

In this case, yeah, it sounds like a storing the answer in a variable  
is the easiest.

One of the things I was getting at was perhaps these arbitrary edit  
divs are all the children/descendants of a div with a particular id?   
Thus your $$ query might be
''#myEditContainer div.edit'' (you could try it with and w/o the
child
selector).


TAG

On May 28, 2007, at 10:24 AM, altay-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
> Here what''s up.  I''ve got an arbitrary number of divs,
with
> class=''qedit'', and
id=''{uniqueid}_qedit''.  The user can click on an
> "edit" link to open up a qedit div for editing, but s/he can only
edit
> one at a time.  In other words, when you click ''edit,'' it
should find
> and close any currently-open divs, and open the div you clicked on.
>
> Hm, now that I actually write out my requirements, I suppose I could
> simply store the currently-open id in a global, which would be a
> little more straightforward.  Doh.  It''s time to refactor.
>
> But, for the sake of discussion -- and cause I''ve run into this
issue
> in other situations -- here''s my original implementation:
> [...]
> There are 15 of these divs on my test page.
>
> For optimization, you can see that I tried four ways to get the
> elements:
> - $$(''.qedit'')
> - document.getElementsByClassName(''qedit'')
> - $$(''div.qedit'')
> - find_elts_by_class( ''div'', ''qedit'') 
--> my own custom function,
> which is not DOM-specific*
>
> Anything else I should try?
>
> Here''s the breakdown:
>
> 4172ms -- $$(''.qedit'')
> 3797ms -- document.getElementsByClassName
> 266ms   -- $$(''div.qedit'')
> 16ms     -- my custom function
>
> So clearly, looking for div.qedit instead of just .qedit helped a lot,
> but it was still trumped by my non-prototype solution.  I don''t
get
> it.  Do you see any glaring errors in my implementation of $$?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Tom Gregory

2007-May-28 19:04 UTC

head link

Re: $$ is slooooow in IE

For a specific application where you know the value of classes you  
can get away with using a regex, but because it''s a fragile  
implementation, it might still be wise to avoid. (A simple == is  
better.)  The reason it''s fragile, is the regexp would also match the  
valid class name "myclass2".  You can''t just wrap the text
string in
"\b" looking for word boundaries, because ''-'' is
valid in class
names, but triggers a "word boundary".

I typed out a handful of other possible optimizations for  
hasClassName based on my recollection of how it was implemented.   
Then I checked the source, and found these optimizations were all  
implemented sometime around the tail end of last year (the old code,  
which is what I remembered, was horribly inefficient). Make sure  
you''re using a recent Prototype version.  The core team put a lot of  
work into speedup of $$, et al.

... One possible speedup of the current hasClassName code (which _is_  
based on a regex), would be to make the groups non-capturing: several  
of the js references I have indicate the regex is faster that way.   
It may be worth testing.

TAG

On May 28, 2007, at 10:42 AM, altay-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
>
> Aha, if I change my custom function to use Element.hasClassName(elt,
> ''myclass'') instead of
elt.className==''myclass'' , then it jumps from
> 16ms to ~250ms.  This matches $$(''div.blah''), which also
took
> ~250ms.
>
> So, FWIW, if you don''t need Element.hasClassName -- that is,
you''re
> only dealing with a single class -- it looks like you can score an
> order of magnitude speed improvement by using "if
> elt.className==''myclass''" instead.
>
> Whoa!  Hold on... even elt.className.match(''myclass'') is
way faster
> (16ms) than hasClassName.  And that takes care of the multiple-
> classname issue, right?
>
> Has anyone done any detailed profiling of hasClassName?  Looks like
> improvements in that might speed up IE''s $$ significantly.
>
> Altay

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

altay-6c8tSettBfPPIjl8wruziA@public.gmane.org

2007-May-28 19:26 UTC

head link

Re: $$ is slooooow in IE

> In this case, yeah, it sounds like a storing the answer in a variable  
> is the easiest.
Yeah, I''m still kicking myself for overcomplicating matters.  Funny
how you can feel so productive during a late-night coding session...
and then wake up to a mess of stupid code.  =P
> One of the things I was getting at was perhaps these arbitrary edit  
> divs are all the children/descendants of a div with a particular id?  
> Thus your $$ query might be
> ''#myEditContainer div.edit'' (you could try it with and
w/o the child
> selector).
Ah, right, thanks for the suggestion.  Unfortunately, since about 95%
of the DOM is inside that parent element, it probably won''t buy me
much.

Sounds like there''s something to this Element.hasClassName ineffiency,
though.  See this recent discussion on the Prototype Core list
(especially the last message):
http://groups.google.com/group/prototype-core/browse_thread/thread/aecbf8e008782d6a
.  This makes it sound like the problem is only with
getElementsByClassName, but perhaps something similar is happening
with the IE implementation of $$?

Tom, thanks for your help with this.

Altay


>
> TAG
>
> On May 28, 2007, at 10:24 AM, a...-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
>
>
>
> > Here what''s up.  I''ve got an arbitrary number of
divs, with
> > class=''qedit'', and
id=''{uniqueid}_qedit''.  The user can click on an
> > "edit" link to open up a qedit div for editing, but s/he can
only edit
> > one at a time.  In other words, when you click
''edit,'' it should find
> > and close any currently-open divs, and open the div you clicked on.
>
> > Hm, now that I actually write out my requirements, I suppose I could
> > simply store the currently-open id in a global, which would be a
> > little more straightforward.  Doh.  It''s time to refactor.
>
> > But, for the sake of discussion -- and cause I''ve run into
this issue
> > in other situations -- here''s my original implementation:
> > [...]
> > There are 15 of these divs on my test page.
>
> > For optimization, you can see that I tried four ways to get the
> > elements:
> > - $$(''.qedit'')
> > - document.getElementsByClassName(''qedit'')
> > - $$(''div.qedit'')
> > - find_elts_by_class( ''div'',
''qedit'')  --> my own custom function,
> > which is not DOM-specific*
>
> > Anything else I should try?
>
> > Here''s the breakdown:
>
> > 4172ms -- $$(''.qedit'')
> > 3797ms -- document.getElementsByClassName
> > 266ms   -- $$(''div.qedit'')
> > 16ms     -- my custom function
>
> > So clearly, looking for div.qedit instead of just .qedit helped a lot,
> > but it was still trumped by my non-prototype solution.  I
don''t get
> > it.  Do you see any glaring errors in my implementation of $$?- Hide
quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

altay-6c8tSettBfPPIjl8wruziA@public.gmane.org

2007-May-28 19:34 UTC

head link

Re: $$ is slooooow in IE

I don''t quite understand what "non-capturing" means --
I''m still
pretty green when it comes to regexps -- but the rest of this makes
sense.  Clearly, a generalized regex-based solution isn''t as trivial
as I made it out to be, but at least this''ll work for a specific
application in a pinch.

You know, thanks to your tip, I just realized that I''m still on
Prototype 1.5.0.  Thought I''d upgraded all my projects, but missed
this one.  We''ll see if 1.5.1 helps.

Altay


On May 28, 3:04 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org>
wrote:> For a specific application where you know the value of classes you  
> can get away with using a regex, but because it''s a fragile  
> implementation, it might still be wise to avoid. (A simple == is  
> better.)  The reason it''s fragile, is the regexp would also match
the
> valid class name "myclass2".  You can''t just wrap the
text string in
> "\b" looking for word boundaries, because ''-''
is valid in class
> names, but triggers a "word boundary".
>
> I typed out a handful of other possible optimizations for  
> hasClassName based on my recollection of how it was implemented.  
> Then I checked the source, and found these optimizations were all  
> implemented sometime around the tail end of last year (the old code,  
> which is what I remembered, was horribly inefficient). Make sure  
> you''re using a recent Prototype version.  The core team put a lot
of
> work into speedup of $$, et al.
>
> ... One possible speedup of the current hasClassName code (which _is_  
> based on a regex), would be to make the groups non-capturing: several  
> of the js references I have indicate the regex is faster that way.  
> It may be worth testing.
>
> TAG
>
> On May 28, 2007, at 10:42 AM, a...-6c8tSettBfPPIjl8wruziA@public.gmane.org
wrote:
>
>
>
>
>
> > Aha, if I change my custom function to use Element.hasClassName(elt,
> > ''myclass'') instead of
elt.className==''myclass'' , then it jumps from
> > 16ms to ~250ms.  This matches $$(''div.blah''), which
also took
> > ~250ms.
>
> > So, FWIW, if you don''t need Element.hasClassName -- that is,
you''re
> > only dealing with a single class -- it looks like you can score an
> > order of magnitude speed improvement by using "if
> > elt.className==''myclass''" instead.
>
> > Whoa!  Hold on... even
elt.className.match(''myclass'') is way faster
> > (16ms) than hasClassName.  And that takes care of the multiple-
> > classname issue, right?
>
> > Has anyone done any detailed profiling of hasClassName?  Looks like
> > improvements in that might speed up IE''s $$ significantly.
>
> > Altay- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Maybe Matching Threads

Search for more possibly parallel threads

Rails spinoffs - May 2007 - $$ is slooooow in IE

$$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Re: $$ is slooooow in IE

Maybe Matching Threads