Right guys, just to report back... I've switched a few things around using the methods you suggested and have noticed a significant increase in speed.
I still need to keep an object in order to store some values, but this method cut down the total objects per element from 4 down to 1, and of course now has no functions attached directly to any of them. As a test (on IE) I loaded 250 items into the list, the old way takes between 2.88 seconds to 3.2 seconds on Average. The same data loaded in the new way ranges between 0.77 secs to 0.8 secs. That's a significant improvement, not to mention that as I load more in IE does not slow down like it did before either. Now, after saying all of that, Chrome loaded the old at around 0.08 & Firefox loaded the old code at 0.3. With the new code they both are around 0.01 and 0.02 seconds. So kudos to both of you for your suggestions, great improvement, thank you! The bottleneck for IE is simply the build-up & rendering of new elements. I currently still have one element though else I cannot store the data in the method I planned. Eliminating the list object entirely (just using plain html instead) makes another radical improvement to IE, with load times of around 0.04 seconds compared to what is written above. I guess another method would be for me to create an array (in memory) and use that instead, rather than storing it in the objects. Each input has a unique ID so this is probably the way to go I guess, unless you can think of reasons not to do it? Thanks again for the help. Ralph On 10 February 2010 08:25, Ralph Slooten <[email protected]> wrote: > 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. >>> >>> >> >
