Hi,
I have a form im creating in MVC3 which contains 30-40 fields and 10 small grids (the content in the page is organized through tabs). So far im just designing the page and loading the fields with dummy data. The grids are not being populated.
On IE9, when the page starts rendering (after all the scripts and css of the page are fetched) it takes 12-17 seconds to complete. Even after it has completed, the page feels clunky. eg. 2 seconds delays when I click to expand a simple combobox or when opening a DatePicker.
In chrome it's much quicker, but doesn't feel as snappy as it should be.
When I remove the grids, all those issues go away. I even tested it on a simple test page with just 3 fields and 9 grids. Same problem.
Any ideas on how I can resolve this?
Thank You
i doubt this is related to the grid data, if you aren't loading any records. the grid doesn't impose any overhead in case there aren't any records. Do you happen to have any features enabled, such as filtering/ sorting, etc?
Could you provide some sample code for one of the grid's configuration ?
Thank you,
Angel
I tested leaving only one tab (thinking of separating the content), so all the grids are gone. But the page still feels slow.
One thing, I miscalculated the controls. There were actually ~60 infragistics controls total and ~50 of them on the first tab.
I ran the F12 Profiler on IE9, and the calls to the offsetWidth property seem to be the ones causing the delays. It takes ~500ms on average to execute all the functions to open a dropdown.
In the Chrome profiler, I don't see any single function/event taking longer than 20ms to execute. The full function call process probably takes around 75ms.
Hi Cperez,
I tested a page which had 40-50 igCombo editors and 40-50 igEditor editors and each of them had 500 items. I did not find any significant delay on load or on drop-down list actions.
Note: if igCombo has more than 300-500 items, then delay on drop-down and/or on list-scroll is possible. If that happens, then I suggest to set "virtualization" option/property of igCombo to true.
Below codes of sample which I tested. You may copy paste those codes in the <body> of any html which has js and css resources required for igEditor and igCombo.
<script type="text/javascript"> $(function () { var i = -1, editData = [], comboData = []; while (i++ < 500) { comboData[i] = {v: 'Value ' + i, t: 'Text ' + i}; editData[i] = 'Value ' + i; } $('.comboCss').igCombo({ dataSource: comboData, valueKey: 'v', textKey: 't' }); $('.editCss').igEditor({ listItems: editData, button: 'dropdown' }); }); </script> <input class="comboCss" /><input class="comboCss" />... (repeat 40-50 times) <br /> <input class="editCss" /><input class="editCss" />... (repeat 40-50 times)
Hi Viktor,
Thank you for looking into this.
I tested your sample with 50 editors and 50 combos. It still felt about the same. I reduced the number of combos to 8, changed the items in them to 75, and made 62 simple editors (no list items) and it does still feel slow to open a combobox when compared to chrome. It's like 500ms difference, but its noticeable.
Another thing I noticed in the last configuration are the load times. In chrome it takes ~2.3s before the Load event is fired; in IE9 it takes ~2.8s; not that much difference. The big difference between the two is the time between DomContentLoaded and the Load event. In chrome the gap is of ~100ms, in IE is 1.7s. I can't go any further in detail than that.
Regards,
Thank you Viktor and Angel.
I'll keep your comments in mind while I design my applications.
Unfortunately different browsers may handle "innocent" javascript statements like offsetWidth/Height, scrollTop/Left, etc. quite differently and generate long delays. Logic of igCombo tries to use as little as possible those statements, but it is not possible to remove them.If you look at structure of html, which creates field and dropdown/clear/spin buttons, then you will probably agree that without usage of offsetWidth/Height/Top/Left, checks for margins, borders, paddings, etc. it would be not possible to do layout of child elements.Those calculations might be avoided if igCombo/igEditor had static predifined size with absolutely all attributes coming from css or style. But igCombo (and latest version of igEditor which is not released yet) supports all html units, including %. Hardly anybody agree to use editor with unchangable width and height.It would be much less calculations, if layout of editor was build on base of TABLE instead of SPAN. But in this case flow layout of application would be not possible and each editor would take new line in browser. Also, TABLE can not be used, because many applications define global css for TD and TR and their attributed may destroy any custom control based on TABLE.
In case of igEditor buttons can be disabled and it will speed up initial load, because only INPUT will be rendered. The dropdown list can be opened by Alt+arrow. But in case of igCombo, it will hardly help, because buttons are always rendered and options may only hide/disable buttons, but not remove them from html.