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.
>>>>
>>>>
>>>
>>
>
