Slow grid performance in IE linked to offsetWidth

[Ryan]

We're experience significantly slower load times IE when loading pages which contain several Kendo grids.  Running the IE and Chrome profilers for this page:

http://plnkr.co/edit/HGDTzRbvi5I1YJuHEznb?p=preview

demonstrates (to some degree) the behavior we are seeing.  Both profilers will show that "offsetWidth" claims the most cpu time.  In Chrome, this accounts for roughly 700 ms.  However, in IE, it accounts for almost 3000 ms.  

This is just a simple example.  But in our case, this disparity is magnitudes worse.  We're comparing load times of 3 sec in Chrome to 55 sec in IE... with almost all of that time (allegedly) attributable to offsetWidth in the profiler.

Is this expected?  Is there any way we can make this faster?

Note: we've been testing in IE 11.

[Kiril Nikolov]

Hello Ryan,

Thank you very much for sharing your observations with us.

We are aware of the slow performance of the offsetWidth property. Currently we cannot change the code behind the Kendo UI Grid to not use the offesetWidth, and unfortunately the performance of the property depends on the browser specific implementation, that we cannot optimize or workaround. 

We are always looking for ways to improve the performance of our component, so if something better comes up, it will be considered and eventually implemented. 

Regards,
Kiril Nikolov
Telerik

 

 

[Rob]

Has anyone found a good solution or workaround for this? The slowness is plaguing us also. 

[Ryan]

To be honest, our solution is going to be avoid using Kendo grids when possible.  We can't tell our clients to stop using IE, we haven't found a workaround and the performance is unacceptable.  So in the cases where we can, we're resorting to a home-grown lighter-weight grid solution.  Still very interested in Telerik addressing this issue directly.

[Kiril Nikolov]

Hi Guys,

As I said already we are aware of the slow performance of the offsetWidth/Height properties in older version of the IE browser, however at the current moment it is not possible to exclude them from the Kendo UI Grid, as they are part of the core functionality that the grid provides. 

We are constantly looking in improving every aspect of the framework, and if you have any suggestions on those improvements, we are always open for them.

Regards,
Kiril Nikolov
Telerik

 

 

[Ryan]

Thanks for the response, but this doesn't really help us much.  If there's truly nothing you can do to make the IE experience better, then we have no choice but to look at other grid solutions.  I'm really not trying to be confrontational about it, but it is the reality.  Also, just so you're aware, we're not using an older version of IE.  This is the most recent IE 11 version.  Thanks.

[Rob]

Agreed - shame I'm going to have to go looking for an open source solution when we pay for Kendo licenses. We are only using one grid, rendering about 400 rows either 1) without row virtualization, cripples the load time with offsetWidth and offsetHeight calls. The grid rendering takes ~4 seconds or 2) turn on row virtualization, and if you use the scroll bar it results in a huge chop/lag each time a virtualization threshold is hit, ~500ms each time.

[Rob]

Also, like Ryan, I'm using IE11 and the latest version of Chrome, happens in both browsers, no difference.

[Kiril Nikolov]

Hello Rob,

Rendering 400 items in a Kendo UI Grid using Chrome browser takes aprox. 140ms Here is a video that I created while testing this:

http://www.screencast.com/t/yuzvCRrgcnc2

You can see the test example here:

http://trykendoui.telerik.com/@Kiril/eweF

Regards,
Kiril Nikolov
Telerik

 

 

[Rob]

For some reason all the samples work, but in our project, setting local virtualization beyond 10 rows or so makes the "virtualization breakpoints" lag heavily. 

We really need something that adds the rows 1 or 5 at a time to the dom instead of rerendering the whole grid with the page size, if that makes sense. The problem is not the number of active dom rows (since scrolling is fine if we turn off virtualization, but then the grid can take 20 seconds to render).

[Atanas Korchev]

Hi Rob,

We are not sure what could be causing this lag in your application. Is there any chance to show us some demo or live URL where this lag can be observed? You can also edit our local virtualization demo here so it mimics your real app: http://trykendoui.telerik.com/@korchev/EPEC

Regards,
Atanas Korchev
Telerik

 

 

[Otto Neff]

Same Problem here, narrowed it also down to the _scrollTo of the Grid.(and the inner native browser functions)

The event of measuring is on cell click by opening CustomEditor with KendoComboBox
 => http://demos.telerik.com/kendo-ui/grid/editing-custom

Same grid, IE11 latest => ~300ms, Chrome 39 => ~4ms <> 100xTIMES slower just to see input after click with custom editor!
Only 300 records. So sample from above doesn't apply.

On enterprise behalf here we can't change the browser (policy, security).. KendoGrid seems to be a future show stopper.

Update to IE11 from IE9 was a big deal. Please consider to think about redesign, use own or alternative functions of the performance killers. New software with Kendo, which is slow than ASP.NET Controls (Telerik JS Client Code) won't be accepted by business users.

Hopefully someone finds a workaround to this... 
Kind regards, Otto.

[Kiril Nikolov]

Hello Otto,

We are constantly looking into improving the performance of the widgets in different browsers. Can you please open a separate support request with a simple runnable example that we can test, as maybe we can suggest some performance improvements. 

Thank you for the cooperation.

Regards,
Kiril Nikolov
Telerik

 

 

[GT]

This may or may not help some in this situation. I had been experiencing very poor performance in IE on a page that had multiple grids. My particular page has many "child" grids, whereby, each grid could lead to more and more child grids depending on the hierarchy of the data I was displaying. In IE, when I got to about 4 levels deep, the rows on the grid would not expand to show more children, it simply "bogged down" and never displayed. In Chrome I had no issues.

After coming to the crisis point many seem to be getting to, I tried turning off grid features. It was not until I removed "Grouping" on the very top level grid that I had success. The top level grid was the only grid with Grouping enabled, but it still had a massive effect on performance, even on the child grids. So I've now checked a lot more areas in my application where I've got Grouping enabled, and sure enough, disabling grouping has had a big impact on performance for IE.

This approach also helped another single grid page where I have put a checkbox on each row. It was taking ages for the browser to register a "click" on a checkbox. After disabling grouping, the click is now normal.

I'm sure this may not help everyone, but it worked for me.

Regards
GT

[Kiril Nikolov]

Hello Garry,

Disabling grouping can give some performance boost in old IE browser, you are correct about that. The reason is that many dataSource calculations are made in order to accommodate the grouping, which can cause some performance hits.

Regards,
Kiril Nikolov
Telerik

 

 

[GT]

Hi Kiril,
 I understand what you are saying, but my experience can not be explained as "some performance boost in old IE browsers". I've been using the latest version of IE, and it was more than just a performance boost. Prior to disabling grouping in the "master" grid, the page was broken....it would take minutes to expand a child grid three levels down in the hierarchy. Also, I was not using any grouping features. Data quantities are small - roughly 10 rows per grid. The child grids did not have grouping enabled...only the top most "master" grid, so I can't see how the "dataSource calculations" you mention have any impact.
 I also found that prior to switching off Grouping, the UI Responsiveness profiler in IE showed hundreds of thousands (that's 100,000s) of calls to offsetWidth, where most of the time was being spent. After switching of Grouping, I no longer see these calls in that quantity.
 Anyhow...these are my observations in my case. I believe something fundamentally changes how the grid handles eventing (like mouse clicks etc) when grouping is enabled, but that's just me speculating. I say this because of my observation of my other grid where I have a checkbox on each row. With grouping enabled, a mouse click on a checkbox would take about 3 seconds to register (with thousands of calls to offsetWidth). Without grouping, the mouse click is registered immediately. I even noticed its not just the checkbox I've added that causes this behavior...the checkbox just makes it apparent/visible. I find that if I click anywhere on a row, I get the same sort of behavior (thousands of calls to offsetWidth)....and I don't even have row selection enabled.

Regards
GT

[Prasanth]

Hi experts,

We are significantly experiencing the performance issue while reading the kendo grid. We are using linq to entities to interact database and it is generating query. After that we are applying "query.AsNoTracking().ToPagedList(criteria.CurrentPage);" here it takes along time to  load as it has almost 400k+ records and it is displaying 20 in the grid as page size is 20. For displaying first 20 records from 400k records it is taking 2 min, for the next 20 records again it is following same process which is far acceptable. We are doing union of two queries and 8 to 10 joins in each linq query. Could anyone suggest how to improve performance of this query. Please respond as soon as possible............thanks in advance

[Kiril Nikolov]

Hi Prasanth,

I am not sure that the issue that you are experiencing is related to the topic of this conversation. So please open a separate support request with your issue and we will be happy to help.

Regards,
Kiril Nikolov
Telerik

 

 

[Roy]

So, after some digging and what not. I came to the conclusion that is was a mouse down event some where. So I don't know all the repructions of doing this. but i was able to speed up my Grid significantly, from 3 seconds / never selecting a row to less then half a second.

 

This is with TypeScript, but isn't too much different then javascript.

if (!!navigator.userAgent.match(/Trident.*rv\:11\./))
{
      var rows = this.KendoGrid.tbody.children("tr[role='row']").toArray();
    rows .forEach(row =>
    {
        var jqueryRow = $(row);
        jqueryRow.on("mousedown", (event) =>
        {
            if (!event.ctrlKey)
            {
                this.KendoGrid.clearSelection();
            }
            else if (event.ctrlKey && jqueryRow.hasClass("k-state-selected"))
            {
                //Do some stuff to unselect the current row and re-select the other rows.
            }
            else
            {
                this.KendoGrid.select(row);
            }
            //This is the part that matters, this Stops Kendo from recalculating offsetwidth on elements multiple times, which is the problem.
            event.stopImmediatePropagation();
            event.preventDefault();
        });
        jqueryRow.on("click", (event) =>
        {
                if (event.ctrlKey)
            {
                                //ctrl is weird and was like selecting and deselecting so this was needed
                event.stopImmediatePropagation();
                event.preventDefault();
            }
        });
    });
}

 

The first line it to just detect IE 11 since it is the only IE version we support.

 

Again I do not know what this will break with Kendo. but the speed improvement is like 100 times better.

[Ron]

I didn't see a comment on this from Telerik.  I'm having trouble just with selections in IE.  Chrome works fine, IE is slow.

 

Is this the same problem you were trying to address?

[Angel Petrov]

Hello,

Guys, in regards of the provided solution we need to check whether such an approach can be integrated as it may break other scenarios that are currently working.

In case of an performance hit I suggest opening a formal support ticket and providing some code that can help us get a better understanding over the exact setup. That would greatly facilitate us in providing a suggestion on how to optimize the performance.

Regards,
Angel Petrov
Telerik by Progress

[Kjell]

Have you guys had a chance to check out Roy's solution?  I took a stab at implementing it but I was not able to get it to work, I'm probably doing something wrong though.  I need a pure JS solution.  I can convert his typescript to JS, but when is it supposed to be called?

[Roy]

I am doing this at the end of the DataBound Function of the kendo.ui.GridOptions.

 

options.dataBound = (e) =>
            {

//WE are doing things like update column widths, re expanding rows, reloading pager and disabling move functionality

 

//Then call the code snippet from above.

}

[Kjell]

Thanks for the quick response Roy, you really made my day.  This made a very noticeable difference for us as well.  I'll update the thread if I find any conflicts with other features or behaviors.