"I really wasnt aware that IE was that bad in dealing with Web Content" There, fixed that for ya ;)
On Wed, Feb 10, 2010 at 2:14 AM, Ralph Slooten <[email protected]> wrote: > One last email for those interested at improving IE performance with > objects ... don't use objects... > > Eliminating the element creation (in the parent UL object) *entirely* and > assigning the "store data" to a global variable hash (identified using the > ID of the child node's input box) has brought IE load time down to from 0.8 > seconds to 0.04 seconds. I now simply do > a userDataStore.get(myLi.getElement('input').id) rather > than myLi.retrieve('data') > > Whilst there still is a delay loading in the data (latency) as the user > scrolls down, the app itself won't get much faster than this! I really > wasn't aware that IE was that bad in dealing with objects, but at least > there is a solution. > > Thanks again, > Ralph > > > On 10 February 2010 11:35, Ralph Slooten <[email protected]> wrote: > >> 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. >>>>> >>>>> >>>> >>> >> > -- --- "Make everything as simple as possible, but not simpler." - Albert Einstein
