Thanks guys for the tips, exactly the kind of advise / help I was looking for.
@Barry: The recursive method is actually what I'm doing already, as in this example there are actually 11,000 entries that can be loaded in. I just auto-load 100 (in IE currently), and if the user scrolls down the next 100 are loaded in etc etc. All the browsers do lock up though while processing those 100 entries, just that all of them are really fast, except IE of course. What takes chromium/ff/opera 0.1 - 0.2 seconds takes IE 1.2-1.8 seconds, and the more I load in (scrolling down) the slower IE becomes. So, on to the next step ~ improving performance using other methods. Using the array formation you suggested, noted. Not sure if it's faster however it looks neater and reads easier ;-) Just to make sure I understand "event delegation" ~ Using the event.delegation plugin, I assign a "global event catcher" to say the UL element using the method explained on http://mootools.net/docs/more/Element/Element.Delegation . This catches my events as I click, ctrl-click, double-click etc anywhere on the UL, and using the selectors calculates which actual element it is, correct? This means that both my input & div's do not need any events assigned. Sounds brilliant, and I'll be sure to use that as I know it will speed up things (I did tests simply not attaching events and it was way faster in IE). @Aaron: Yes, another of my tests shows pure HTML being set in the element as being much faster than object formation. The issue I was having was no way of attaching events. Having said that, and if I understand it correctly, with Element Delegation it won't matter how I created the children as the selectors will be looking for html elements and not objects. I'll do my changes today and report back. Thanks again for the tips guys! Appreciated. Regards, Ralph On 9 February 2010 22:48, Aaron Newton <[email protected]> wrote: > ++ on the delegation tip. I also suggest considering constructing the html > as a string and setting innerHtml (parent.set('html', str)); IE can process > this a bit faster than using the element constructor en masse. If you use > delegation, you shouldn't have to reference them all on startup. > > > On Tue, Feb 9, 2010 at 1:35 AM, Barry van Oudtshoorn < > [email protected]> wrote: > >> Hiya, >> >> Although this won't actually increase performance, you can increase >> *perceived* performance by altering the way you process each of your "user" >> items. If you use a recursive approach, such that once each item is finished >> being processed, it sets the next one processing, and put in a 1 or 2ms >> delay on each call, the browser won't lock up, so your spinners will keep >> spinning, you won't risk the "unresponsive script" dialog, and everything >> just seems to work faster. :) >> >> Looking at the code, I notice that you attach event handlers to every >> element. These may well impact negatively on performance in all browsers. >> You might want to have a look at event delegation -- this will reduce the >> number of event handlers on the page, and also cut down on some of the code >> in your snippet. Oh, and instead of using "new Array()", you're probably >> better off just using an array literal... although it looks like your dta >> "array" should actually be an object... perhaps consider rewriting that >> section as >> >> var dta = { >> itemID: usr.i, >> firstname: usr.f, >> // ... and so on >> } >> >> Regards, >> >> Barry >> >> >> On 09/02/10 17:03, Ralph Slooten wrote: >> >> Hi guys, >> >> I have what I believe to be a generic problem, namely poor performance >> with Internet Explorer when dealing with hundreds of objects. I'm currently >> working with something similar to the gmail address book, although what I >> have dynamically loads in addresses using an ajax call as a user scrolls >> down. The structure of each element group is simply >> <li> >> <label> >> <input type=checkbox" /> >> <div>Some short data</div> >> </label> >> </li> >> >> The input & the div elements have attached events (differing) and the >> list (li) element has an small array stored in the Elements Storage. >> >> I've been careful when creating the array to group actions as far as >> possible, so I'm left with something to the effect of: >> >> result.users.each(function(usr){ >> var myLi = new Element('li'); >> var myLabel = new Element('label').inject(myLi); >> var sel = new Element('input', {'id':'check'+i, 'type': 'checkbox', >> events:{ >> 'change': function() {styleList(myLi);}, >> 'click': function(){clickage(event);} >> }}).inject(myLabel); >> var usrData = new Element('div', { 'text': usr.f+' '+usr.l, events: { >> 'click': function(event){if(!event.control) selectNone();}, >> 'dblclick':function(){editUser();} >> }}).inject(myLabel); >> var dta = new Array(); >> dta.itemID = usr.i; >> dta.firstname = usr.f; >> dta.lastname = usr.l; >> dta.groups = usr.g; >> dta.email = usr.e; >> myLi.store('data', dta); >> myLi.inject(myUL); >> }); >> >> This is repeated for 100 addresses at a time, although all other >> browsers easily handle 250, 500 and even 1000 faster than IE does 100. >> >> IE performance just sucks. Chrome, FF, Opera, Safari, all extremely >> fast. Is there some obvious way to improve performance? If I just inject >> text it speeds up dramatically (on IE), however I cannot attach the >> necessary functions. Just creating the div almost doubles the load time. >> >> Any suggestions? Thanks in advance. >> >> Cheers, >> Ralph >> >> >> >> -- >> Not sent from my iPhone. >> >> >
