tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Aug-09 04:22 UTC
Event.observe 1800% slower in IE?
Hi all, I have an application that relies heavily on Event.observe, but I''m finding that in IE (tested mostly in 6), it is about 18 times slower. For me, this adds about six seconds to every action on my app for Internet Explorer users, and I have to figure out a workaround.. Here''s a quick code sample on my website that demos what I''m referring to: http://igargoyle.com/tests/ie_proto_event_observe_is_slower/ Hope you can help! Thanks, Tom Longson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Just FYI, I tested this in IE7 and got between 4 and 8 times slower (rather inconsistent). On Aug 8, 9:22 pm, "toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi all, > > I have an application that relies heavily on Event.observe, but I''m > finding that in IE (tested mostly in 6), it is about 18 times slower. > For me, this adds about six seconds to every action on my app for > Internet Explorer users, and I have to figure out a workaround.. > > Here''s a quick code sample on my website that demos what I''m referring > to: > > http://igargoyle.com/tests/ie_proto_event_observe_is_slower/ > > Hope you can help! > > Thanks, > Tom Longson--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
<snip>
for (i=0; i < 4000; i++) {
var el = document.createElement("div");
el.className = "dot";
document.body.appendChild(el);
Event.observe(el, ''mouseover'', function(e) {
Element.setStyle
(Event.element(e), {background: "#00FF00"}); }.bindAsEventListener
(this), false);
}
</snip>
Given your "test", how do you know the slowdown is with
Event.observe, and not document.createElement (which _is_ slow)?
HTMLElement.clone is faster than document.createElement (which is
horrendously slow on IE); using innerHTML is an order of magnitude
faster than both. [1]
In addition to how you''re creating the element, you''re also
causing a
bit of slowdown (and additional memory use) by creating an anonymous
function on each iteration, and binding on each iteration (which
creates anonymous closures) rather than once and caching the result.
e.x.
var f = function (e) {Event.element(e).setStyle({background:
"#00ff00"});}.bindAsEventListener(this);
for (i = 0; i < 4000; i++) {
// ...
Event.observe(el, ''mouseover'', f);
}
If you want to prove Event.observe is slow in IE, you''ll need to
write a (much) better test.
TAG
1. http://www.quirksmode.org/dom/innerhtml.html
On Aug 8, 2007, at 10:22 PM, tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wrote:
>
> Hi all,
>
> I have an application that relies heavily on Event.observe, but
I''m
> finding that in IE (tested mostly in 6), it is about 18 times slower.
> For me, this adds about six seconds to every action on my app for
> Internet Explorer users, and I have to figure out a workaround..
>
> Here''s a quick code sample on my website that demos what
I''m referring
> to:
>
> http://igargoyle.com/tests/ie_proto_event_observe_is_slower/
>
> Hope you can help!
>
> Thanks,
> Tom Longson
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
I believe the slowness is caused by the speed (or lack thereof) of
extending each element during the call to Event.observe (element=$
(element)) in IE. Using the new DOM Builder functionality in the trunk
branch (http://www.prototypejs.org/2007/5/12/dom-builder) and
replacing
var el=document.createElement("div");
el.className = "dot";
with
var el = new Element(''div'',{className :
"dot"}); //Uses the
DOM Builder functionality to create the element already extended
brings the speeds of the browsers much closer together
Tom
On Aug 8, 9:29 pm, Chippy
<firemulholl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Just FYI, I tested this in IE7 and got between 4 and 8 times slower
> (rather inconsistent).
>
> On Aug 8, 9:22 pm,
"toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Hi all,
>
> > I have an application that relies heavily on Event.observe, but
I''m
> > finding that in IE (tested mostly in 6), it is about 18 times slower.
> > For me, this adds about six seconds to every action on my app for
> > Internet Explorer users, and I have to figure out a workaround..
>
> > Here''s a quick code sample on my website that demos what
I''m referring
> > to:
>
> >http://igargoyle.com/tests/ie_proto_event_observe_is_slower/
>
> > Hope you can help!
>
> > Thanks,
> > Tom Longson
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
> I have an application that relies heavily on Event.observe, but I''m > finding that in IE (tested mostly in 6), it is about 18 times slower. > For me, this adds about six seconds to every action on my app for > Internet Explorer users, and I have to figure out a workaround..I use IE 6 and your page tells me it''s Firefox :) So I must have a speedy Internet Explorer Total time: 0:19:907 ...you must be using Firefox I testes 3 times - just about same result. Regards Thomas --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
fwiw, i see 0:0:771 w/ IE 6, 0:0:717 w/ FF2 Mac, 0:0:164 Safari 3 (Mac) all three tell me i''m on firefox... :) best, thomas Am 09.08.2007 um 11:53 schrieb Thomas K. Nielsen:> >> I have an application that relies heavily on Event.observe, but I''m >> finding that in IE (tested mostly in 6), it is about 18 times slower. >> For me, this adds about six seconds to every action on my app for >> Internet Explorer users, and I have to figure out a workaround.. > > I use IE 6 and your page tells me it''s Firefox :) > So I must have a speedy Internet Explorer > Total time: 0:19:907 ...you must be using Firefox > I testes 3 times - just about same result. > > Regards > Thomas > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It would. Although again I disagree with your conclusion as to why. (But it does reinforce my previous assertion that most of the slowdown you were seeing was due to element creation.) The prototype DOM builder uses a technique unique to IE to create the elements (in IE only), which (being similar to the innerHTML solution which has been proven to be decently fast in IE), is much faster than document.createElement. I don''t buy the "slowness caused by extending" argument, because a) it didn''t go away in your new test, and yet you saw speedup, and b) Prototype''s DOM builder (i.e. new Element) extends elements too. Oh, ... and there are too many Tom''s on this thread. Some of you will have to change your name. =) TAG On Aug 9, 2007, at 1:05 AM, Tom wrote:> I believe the slowness is caused by the speed (or lack thereof) of > extending each element during the call to Event.observe (element=$ > (element)) in IE. Using the new DOM Builder functionality in the trunk > branch (http://www.prototypejs.org/2007/5/12/dom-builder) and > replacing > > var el=document.createElement("div"); > el.className = "dot"; > > with > > var el = new Element(''div'',{className : "dot"}); //Uses the > DOM Builder functionality to create the element already extended > > brings the speeds of the browsers much closer together > > Tom--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Just to clarify a couple of things, here''s how new Element works: 1. we use document.createElement the first time its called, extend the generated element and cache it. 2. when you create a second element with the same tag name, we just clone the cached element. The IE "technique" you are referring to is just a special casing for IE ''s poor handling of the name attribute. Hope this helps, Regards, Tobie 2. we store a cloned Extended version of t On Aug 9, 8:06 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> It would. Although again I disagree with your conclusion as to why. > (But it does reinforce my previous assertion that most of the > slowdown you were seeing was due to element creation.) > > The prototype DOM builder uses a technique unique to IE to create the > elements (in IE only), which (being similar to the innerHTML solution > which has been proven to be decently fast in IE), is much faster than > document.createElement. > > I don''t buy the "slowness caused by extending" argument, because a) > it didn''t go away in your new test, and yet you saw speedup, and b) > Prototype''s DOM builder (i.e. new Element) extends elements too. > > Oh, ... and there are too many Tom''s on this thread. Some of you > will have to change your name. =) > > TAG > > On Aug 9, 2007, at 1:05 AM, Tom wrote: > > > I believe the slowness is caused by the speed (or lack thereof) of > > extending each element during the call to Event.observe (element=$ > > (element)) in IE. Using the new DOM Builder functionality in the trunk > > branch (http://www.prototypejs.org/2007/5/12/dom-builder) and > > replacing > > > var el=document.createElement("div"); > > el.className = "dot"; > > > with > > > var el = new Element(''div'',{className : "dot"}); //Uses the > > DOM Builder functionality to create the element already extended > > > brings the speeds of the browsers much closer together > > > Tom--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Aug-09 19:26 UTC
Re: Event.observe 1800% slower in IE?
Improving my test with the comments that you guys made, I first made
it run twice, once with without Event.observe, and then with
Event.observe. Both use non-anonymous events now as well in case that
had any effect. I also removed the silly browser identification since
Thomas probably has a much better computer than I do. There seems to
be some variance between runs, but this is still helpful in
understanding what''s going on.
Under Firefox, I get the following times (http://igargoyle.com/tests/
ie_proto_event_observe_is_slower/test2.html)
Total time: 0:0:610 [without Event.observe call]
Total time: 0:0:625 [without Event.observe call]
Total time: 0:0:625 [without Event.observe call]
Total time: 0:2:125 [with Event.observe call]
Total time: 0:2:453 [with Event.observe call]
Total time: 0:1:953 [with Event.observe call]
Likewise, in IE 7 (I don''t have 6 on my laptop, please post your
results):
Total time: 0:0:281 [without Event.observe call]
Total time: 0:0:281 [without Event.observe call]
Total time: 0:0:281 [without Event.observe call]
Total time: 0:8:531 [with Event.observe call]
Total time: 0:8:765 [with Event.observe call]
Total time: 0:8:641 [with Event.observe call]
Actually got an improvement on the basic DOM creation, but the
Event.observe accounted for approximately a 3x increase.
So taking "Tom" ''s advice to use "new
Element(''div'',{className :
"dot"});" (very cool, cheers), I get the following times:
Firefox (http://igargoyle.com/tests/ie_proto_event_observe_is_slower/
test3.html)
Total time: 0:0:719 [without Event.observe call]
Total time: 0:0:766 [without Event.observe call]
Total time: 0:0:750 [without Event.observe call]
Total time: 0:3:578 [with Event.observe call]
Total time: 0:3:422 [with Event.observe call]
Total time: 0:2:953 [with Event.observe call]
Internet Explorer:
Total time: 0:0:672 [without Event.observe call]
Total time: 0:0:765 [without Event.observe call]
Total time: 0:0:766 [without Event.observe call]
Total time: 0:2:719 [with Event.observe call]
Total time: 0:2:703 [with Event.observe call]
Total time: 0:2:485 [with Event.observe call]
Also, since there are so many Tom''s on this mailing list, just call me
"nym". Hope these tests are helpful in improving prototype. Is this a
(much) better test now?
nym
On Aug 9, 10:27 am, Tobie Langel
<tobie.lan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Just to clarify a couple of things, here''s how new Element works:
>
> 1. we use document.createElement the first time its called, extend the
> generated element and cache it.
> 2. when you create a second element with the same tag name, we just
> clone the cached element.
>
> The IE "technique" you are referring to is just a special casing
for
> IE ''s poor handling of the name attribute.
>
> Hope this helps,
>
> Regards,
>
> Tobie
>
> 2. we store a cloned Extended version of t
> On Aug 9, 8:06 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org>
wrote:
>
> > It would. Although again I disagree with your conclusion as to why.
> > (But it does reinforce my previous assertion that most of the
> > slowdown you were seeing was due to element creation.)
>
> > The prototype DOM builder uses a technique unique to IE to create the
> > elements (in IE only), which (being similar to the innerHTML solution
> > which has been proven to be decently fast in IE), is much faster than
> > document.createElement.
>
> > I don''t buy the "slowness caused by extending"
argument, because a)
> > it didn''t go away in your new test, and yet you saw speedup,
and b)
> > Prototype''s DOM builder (i.e. new Element) extends elements
too.
>
> > Oh, ... and there are too many Tom''s on this thread. Some of
you
> > will have to change your name. =)
>
> > TAG
>
> > On Aug 9, 2007, at 1:05 AM, Tom wrote:
>
> > > I believe the slowness is caused by the speed (or lack thereof)
of
> > > extending each element during the call to Event.observe
(element=$
> > > (element)) in IE. Using the new DOM Builder functionality in the
trunk
> > > branch (http://www.prototypejs.org/2007/5/12/dom-builder) and
> > > replacing
>
> > > var el=document.createElement("div");
> > > el.className = "dot";
>
> > > with
>
> > > var el = new Element(''div'',{className :
"dot"}); //Uses the
> > > DOM Builder functionality to create the element already extended
>
> > > brings the speeds of the browsers much closer together
>
> > > Tom
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
On Aug 9, 2007, at 1:26 PM, tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:> Also, since there are so many Tom''s on this mailing list, just call me > "nym".It''s really a bit of an unusual experience for me. Family reunions excepted, I''ve never come across as many Toms in one place. (And I really was kidding about picking a name other than "Tom" ;)> Is this a (much) better test now?Yes. For starters your now better describing the test as "create and observe" rather than just "observe", and are attempting to control for creation. This is important, as your claim was based on Event.observe. As you can see between your results in test2 and test3, a good chunk of the variation was from element creation. (IE is much faster on element creation using Prototype''s method; Firefox is marginally slower.) But, the test can still use some minor improvement. You''re still seeing some slowdown by binding on each iteration (which is creating a unique closure each time), rather than binding once and caching the result. i.e., not: for (i=0; i < 4000; i++) { // ... Event.observe(el, ''mouseover'', changeColor.bindAsEventListener (this), false); // ... } ... but rather this, only creating the closure once: var f = changeColor.bindAsEventListener(this); for (i=0; i < 4000; i++) { // ... Event.observe(el, ''mouseover'', f, false); // ... } By binding each time, you''re creating another place that might be the cause of significant slowdown. Actually, I''m not sure why you''re binding at all--this test doesn''t need to. If it''s just to ensure the event gets passed to the callback, Event.observe already handles that for you. e.g. for (i=0; i < 4000; i++) { // ... Event.observe(el, ''mouseover'', changeColor, false); // ... } I don''t expect enormous speedup from this change, but I do expect noticeable speedup (which is not included in numbers, below). If you take the difference between average "creation" and average "create+observe", you get an approximate time of Event.Observe. (This may not be entirely accurate, but close enough.) Your test results show IE may actually be __faster than Firefox__ w/ Event.observe: (using your numbers, as I don''t have IE): Firefox (avg("create+observe") - avg("create") = approx avg("observe")): 3:318 - 0:745 = approx 2:573s. IE (avg("create+observe") - avg("create")= approx avg("observe")): 2.636 - 0:734 = approx 1:902s. TAG P.S. You may also find this link of interest as you seek to optimize your current app, which IIRC, is what prompted this test. It includes loop optimization suggestion, including reverse loop counting, unrolling, and Duff''s Device: http://home.earthlink.net/~kendrasg/info/js_opt/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
... and I neglected to mention, you may also see speedup by appending your new elements to a "holder" div that''s not attached to the DOM, then attaching them to the DOM all at once at the end of the loop. TAG --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Aug-09 23:17 UTC
Re: Event.observe 1800% slower in IE?
So my original code sample was based on my application, which happened to use bindAsEventListener(). I didn''t know if that was potentially causing a major problem in IE6, but I still don''t feel like I have a great solution to the problem. The problem isn''t especially due to the DOM creation, I just did that to try it out (again, cool). Not being at a computer with IE6, I can''t see if my new test is faster than I originally said, but there still is a *serious* slowdown when I do Event.observe on IE6, and I''m not sure how to improve it. This is still a bit rough, but my code is here if you want to see the exact example: http://stage.whypaysticker.com/showroom/ Lines 744 - 755 of controller.js are the Event.observe calls (I was trying to replace them, hence the comments). I''ve been working on this for some time, but I''d love some senior feedback. Thanks, nym (been using this handle for many years) On Aug 9, 1:23 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> On Aug 9, 2007, at 1:26 PM, toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: > > > Also, since there are so many Tom''s on this mailing list, just call me > > "nym". > > It''s really a bit of an unusual experience for me. Family reunions > excepted, I''ve never come across as many Toms in one place. (And I > really was kidding about picking a name other than "Tom" ;) > > > Is this a (much) better test now? > > Yes. For starters your now better describing the test as "create and > observe" rather than just "observe", and are attempting to control > for creation. This is important, as your claim was based on > Event.observe. As you can see between your results in test2 and > test3, a good chunk of the variation was from element creation. (IE > is much faster on element creation using Prototype''s method; Firefox > is marginally slower.) But, the test can still use some minor > improvement. You''re still seeing some slowdown by binding on each > iteration (which is creating a unique closure each time), rather than > binding once and caching the result. > > i.e., not: > > for (i=0; i < 4000; i++) { > // ... > Event.observe(el, ''mouseover'', changeColor.bindAsEventListener > (this), false); > // ... > > } > > ... but rather this, only creating the closure once: > > var f = changeColor.bindAsEventListener(this); > for (i=0; i < 4000; i++) { > // ... > Event.observe(el, ''mouseover'', f, false); > // ... > > } > > By binding each time, you''re creating another place that might be the > cause of significant slowdown. Actually, I''m not sure why you''re > binding at all--this test doesn''t need to. If it''s just to ensure > the event gets passed to the callback, Event.observe already handles > that for you. > > e.g. > for (i=0; i < 4000; i++) { > // ... > Event.observe(el, ''mouseover'', changeColor, false); > // ... > > } > > I don''t expect enormous speedup from this change, but I do expect > noticeable speedup (which is not included in numbers, below). > > If you take the difference between average "creation" and average > "create+observe", you get an approximate time of Event.Observe. (This > may not be entirely accurate, but close enough.) Your test results > show IE may actually be __faster than Firefox__ w/ Event.observe: > (using your numbers, as I don''t have IE): > > Firefox (avg("create+observe") - avg("create") = approx avg("observe")): > 3:318 - 0:745 = approx 2:573s. > > IE (avg("create+observe") - avg("create")= approx avg("observe")): > 2.636 - 0:734 = approx 1:902s. > > TAG > > P.S. You may also find this link of interest as you seek to optimize > your current app, which IIRC, is what prompted this test. It includes > loop optimization suggestion, including reverse loop counting, > unrolling, and Duff''s Device:http://home.earthlink.net/~kendrasg/info/js_opt/--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Just wondering, but is there any reason that you are adding an event observer per icon? You should be able to easily add an event observer per row (or for the whole table) and handle the events there, which would considerably cut down on the number of event handlers registered. Tom --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Aug-10 00:17 UTC
Re: Event.observe 1800% slower in IE?
Each icon changes when you mouseover them, and they also have associated behavior when you click on them. If there''s a better way to associate the events, I''d love to hear it. nym On Aug 9, 4:59 pm, Tom <twalp...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Just wondering, but is there any reason that you are adding an event > observer per icon? You should be able to easily add an event observer > per row (or for the whole table) and handle the events there, which > would considerably cut down on the number of event handlers > registered. > > Tom--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Aug 9, 2007, at 5:17 PM, tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:> > So my original code sample was based on my application, which happened > to use bindAsEventListener(). ... I > originally said, but there still is a *serious* slowdown when I do > Event.observe on IE6, and I''m not sure how to improve it. > > This is still a bit rough, but my code is here if you want to see the > exact example: > > http://stage.whypaysticker.com/showroom/Looks like a fun project. My suggestions (some are repeats from earlier emails): 1. Don''t use json.js. It conflicts with many other libraries. You also don''t need it--current Prototype versions have JSON support built in. 2. You''re still doing the binding inside the loop instead of outside. Bind once, use the reference inside the loop. 3. I like the other Tom''s suggestion re the onclick event observing, although I''d take it a step further: observe only #carBrowser, not each row. You can then use Prototype''s findElement() function [a] to zero in programmatically on which div was clicked. e.g. Event.findElement(evt, ''div'');, which should give you the div closest (stepping up the tree) to the click location. This is what event bubbling was created for! Take advantage of it. a. http://prototypejs.org/api/event/findElement 4. The mouseouver/mouseout stuff really belongs in CSS (where it would be wicked fast). I know IE6 has trouble with :hover unless it''s dealing w/ <a>, so that might require adding some <a> tags to your markup ... but if speed is your primary concerns, I think it''d be worth the trade-off. Even if you choose not to move it to CSS, you could use a similar Event.findElement trick as suggested above, and only apply the observer to the rows rather than the individual icons. 5. If speedup is your primary concern, use a reverse loop, not each (). Each() is a great convenience method when speed costs are negligible, but does have a small performance cost associated with it. http://home.earthlink.net/~kendrasg/info/js_opt/ for (i = arr.length; i < 0; i--) { } 6. Instead of firing off an Ajax GET call immediately on page load, load the correct content from the server the first time. 7. Append your many new elements to an element/document fragment that''s not part of the main DOM. Then attach it all at once. It''ll be faster than adding ''em to the main DOM one at a time. TAG --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
You can attach the event observers for the icons to the row instead (1 per row instead of 1 per icon), let the event "bubble" up from the icon to the row and use Event.element(e) to determine which icon the event came from. You''re already doing something similar for highlightRow, except there you''re getting the parent of the element the event bubbles from to see if it is the row. Tom On Aug 9, 5:17 pm, "toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Each icon changes when you mouseover them, and they also have > associated behavior when you click on them. If there''s a better way to > associate the events, I''d love to hear it. > > nym > > On Aug 9, 4:59 pm, Tom <twalp...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Just wondering, but is there any reason that you are adding an event > > observer per icon? You should be able to easily add an event observer > > per row (or for the whole table) and handle the events there, which > > would considerably cut down on the number of event handlers > > registered. > > > Tom--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
AH, I missed TAGs response (which is much more thorough) while typing mine - I like all of the suggestions :) Tom On Aug 9, 5:38 pm, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> On Aug 9, 2007, at 5:17 PM, toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: > > > > > So my original code sample was based on my application, which happened > > to use bindAsEventListener(). ... I > > originally said, but there still is a *serious* slowdown when I do > > Event.observe on IE6, and I''m not sure how to improve it. > > > This is still a bit rough, but my code is here if you want to see the > > exact example: > > >http://stage.whypaysticker.com/showroom/ > > Looks like a fun project. My suggestions (some are repeats from > earlier emails): > > 1. Don''t use json.js. It conflicts with many other libraries. You > also don''t need it--current Prototype versions have JSON support > built in. > > 2. You''re still doing the binding inside the loop instead of > outside. Bind once, use the reference inside the loop. > > 3. I like the other Tom''s suggestion re the onclick event observing, > although I''d take it a step further: observe only #carBrowser, not > each row. You can then use Prototype''s findElement() function [a] > to zero in programmatically on which div was clicked. e.g. > Event.findElement(evt, ''div'');, which should give you the div closest > (stepping up the tree) to the click location. This is what event > bubbling was created for! Take advantage of it. > a.http://prototypejs.org/api/event/findElement > > 4. The mouseouver/mouseout stuff really belongs in CSS (where it > would be wicked fast). I know IE6 has trouble with :hover unless > it''s dealing w/ <a>, so that might require adding some <a> tags to > your markup ... but if speed is your primary concerns, I think it''d > be worth the trade-off. Even if you choose not to move it to CSS, you > could use a similar Event.findElement trick as suggested above, and > only apply the observer to the rows rather than the individual icons. > > 5. If speedup is your primary concern, use a reverse loop, not each > (). Each() is a great convenience method when speed costs are > negligible, but does have a small performance cost associated with it. > > http://home.earthlink.net/~kendrasg/info/js_opt/ > for (i = arr.length; i < 0; i--) { > > } > > 6. Instead of firing off an Ajax GET call immediately on page load, > load the correct content from the server the first time. > > 7. Append your many new elements to an element/document fragment > that''s not part of the main DOM. Then attach it all at once. It''ll > be faster than adding ''em to the main DOM one at a time. > > TAG--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Aug 10, 9:17 am, "toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> So my original code sample was based on my application, which happened > to use bindAsEventListener(). I didn''t know if that was potentially > causing a major problem in IE6, but I still don''t feel like I have a > great solution to the problem. The problem isn''t especially due to the > DOM creation, I just did that to try it out (again, cool). Not being > at a computer with IE6, I can''t see if my new test is faster than I > originally said, but there still is a *serious* slowdown when I do > Event.observe on IE6, and I''m not sure how to improve it.Then don''t use Event.observe. It''s really only necessary when you want to add more than one handler to a particular intrinsic event. Your original example could be: function changeColour(){ this.style.backgroundColor = ''#00FF00''; } function doEeet() { var startTime = new Date(); var i = 4000; var body = document.body; while (i--) { var el = document.createElement("div"); el.className = "dot"; el.onmouseover = changeColour; body.appendChild(el); } el = null; $(''totalTime'').innerHTML = new Date() - startTime + '' ms''; } doEeet(); Which runs in IE 6 about 3 times faster than Firefox (for me, about 170ms versus 630ms).> This is still a bit rough, but my code is here if you want to see the > exact example: > > http://stage.whypaysticker.com/showroom/ > > Lines 744 - 755 of controller.js are the Event.observe calls (I was > trying to replace them, hence the comments). I''ve been working on this > for some time, but I''d love some senior feedback.Why on earth do you add a reset button to a form by adding a plain button, then using script to call the form''s reset method? Replace all those individual events with one single event that detects the element clicked on and acts accordingly. -- Rob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
tomlong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Aug-11 02:01 UTC
Re: Event.observe 1800% slower in IE?
IE 6 Test times for test 2: Total time: 0:0:640 [without Event.observe call] Total time: 0:0:485 [without Event.observe call] Total time: 0:0:516 [without Event.observe call] Total time: 0:26:281 [with Event.observe call] Total time: 0:25:938 [with Event.observe call] Total time: 0:25:766 [with Event.observe call] On my destop the average for Internet Explorer 6 is as follows: IE6 - 25.96 On my laptop the averages were: IE7- 8.63 FF2 - 2.20 Still a major slowdown even with the initial suggestions that were made. nym On Aug 9, 9:04 pm, RobG <rg...-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org> wrote:> On Aug 10, 9:17 am, "toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <toml...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > So my original code sample was based on my application, which happened > > to use bindAsEventListener(). I didn''t know if that was potentially > > causing a major problem in IE6, but I still don''t feel like I have a > > great solution to the problem. The problem isn''t especially due to the > > DOM creation, I just did that to try it out (again, cool). Not being > > at a computer with IE6, I can''t see if my new test is faster than I > > originally said, but there still is a *serious* slowdown when I do > > Event.observe on IE6, and I''m not sure how to improve it. > > Then don''t use Event.observe. It''s really only necessary when you > want to add more than one handler to a particular intrinsic event. > Your original example could be: > > function changeColour(){ > this.style.backgroundColor = ''#00FF00''; > } > > function doEeet() { > var startTime = new Date(); > var i = 4000; > var body = document.body; > while (i--) { > var el = document.createElement("div"); > el.className = "dot"; > el.onmouseover = changeColour; > body.appendChild(el); > } > el = null; > $(''totalTime'').innerHTML = new Date() - startTime + '' ms''; > } > > doEeet(); > > Which runs in IE 6 about 3 times faster than Firefox (for me, about > 170ms versus 630ms). > > > This is still a bit rough, but my code is here if you want to see the > > exact example: > > >http://stage.whypaysticker.com/showroom/ > > > Lines 744 - 755 of controller.js are the Event.observe calls (I was > > trying to replace them, hence the comments). I''ve been working on this > > for some time, but I''d love some senior feedback. > > Why on earth do you add a reset button to a form by adding a plain > button, then using script to call the form''s reset method? > > Replace all those individual events with one single event that detects > the element clicked on and acts accordingly. > > -- > Rob--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Aug 10, 6:26 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote:> ... and I neglected to mention, you may also see speedup by appending > your new elements to a "holder" div that''s not attached to the DOM, > then attaching them to the DOM all at once at the end of the loop.The following article on MSDN suggests that isn''t a good idea as it may cause a memory leak: <URL: http://msdn2.microsoft.com/en-us/library/Bb250448.aspx > -- Rob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Aug 11, 2007, at 4:38 AM, RobG wrote:> On Aug 10, 6:26 am, Tom Gregory <t...-PGZyUNKar/Q@public.gmane.org> wrote: >> ... and I neglected to mention, you may also see speedup by appending >> your new elements to a "holder" div that''s not attached to the DOM, >> then attaching them to the DOM all at once at the end of the loop. > > The following article on MSDN suggests that isn''t a good idea as it > may cause a memory leak: > > <URL: http://msdn2.microsoft.com/en-us/library/Bb250448.aspx >Cool article. Thanks for the link. I''m not entirely sure the leak applies in this situation, though. It''s emphasized that the (very small) leak is caused when this is done with elements that have inline scripts. It doesn''t explain whether scripts attached via attachEvent (or in Prototype, Event.Observe) would also have this problem. I''d have to test it. The workaround they suggest is to append elements as I described, then go back and attach scripts once all of the elements are in the DOM. In the project at hand, one of the recommendations to Tom was to attach observers farther up the tree than he''s doing, so this approach would be trivial. From the article: "The key points to understand about the leak are that DOM elements are being created with scripts already attached. This is actually crucial to the leak, because if we create DOM elements that don''t contain any script and attach them together in the same manner we don''t have a leak problem. This gives rise to a second workaround that might be even better for larger subtrees (in the example we only have two elements, so building the tree off the primary DOM isn''t a performance hit). The second workaround would be to create your elements with no scripts attached initially so that you can safely build your subtree. After you''ve attached your subtree to the primary DOM, go back and wire up any script events at that point. Remember to follow the principles for circular references and closures so you don''t cause a different leak in your code as you hook up your events." Again, thanks for the link--it was an interesting article. TAG --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---