Slow grid performance in IE linked to offsetWidth

18 posts, 0 answers
  1. Ryan
    Ryan avatar
    8 posts
    Member since:
    Oct 2012

    Posted 12 Mar 2014 Link to this post

    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.
  2. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 17 Mar 2014 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  3. UI for ASP.NET Ajax is Ready for VS 2017
  4. Rob
    Rob avatar
    5 posts
    Member since:
    Dec 2011

    Posted 22 Apr 2014 Link to this post

    Has anyone found a good solution or workaround for this? The slowness is plaguing us also. 
  5. Ryan
    Ryan avatar
    8 posts
    Member since:
    Oct 2012

    Posted 24 Apr 2014 in reply to Rob Link to this post

    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.
  6. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 25 Apr 2014 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  7. Ryan
    Ryan avatar
    8 posts
    Member since:
    Oct 2012

    Posted 25 Apr 2014 in reply to Kiril Nikolov Link to this post

    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.
  8. Rob
    Rob avatar
    5 posts
    Member since:
    Dec 2011

    Posted 25 Apr 2014 in reply to Ryan Link to this post

    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.
  9. Rob
    Rob avatar
    5 posts
    Member since:
    Dec 2011

    Posted 25 Apr 2014 in reply to Rob Link to this post

    Also, like Ryan, I'm using IE11 and the latest version of Chrome, happens in both browsers, no difference.
  10. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 29 Apr 2014 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  11. Rob
    Rob avatar
    5 posts
    Member since:
    Dec 2011

    Posted 01 May 2014 in reply to Kiril Nikolov Link to this post

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

  12. Atanas Korchev
    Admin
    Atanas Korchev avatar
    8462 posts

    Posted 06 May 2014 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  13. Otto Neff
    Otto Neff avatar
    36 posts
    Member since:
    Jul 2011

    Posted 19 Jan 2015 Link to this post

    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.


















  14. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 21 Jan 2015 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  15. GT
    GT avatar
    2 posts
    Member since:
    May 2007

    Posted 02 Apr 2015 Link to this post

    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
  16. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 03 Apr 2015 Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  17. GT
    GT avatar
    2 posts
    Member since:
    May 2007

    Posted 03 Apr 2015 in reply to Kiril Nikolov Link to this post

    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


  18. Prasanth
    Prasanth avatar
    5 posts
    Member since:
    Jan 2016

    Posted 01 Apr Link to this post

    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

  19. Kiril Nikolov
    Admin
    Kiril Nikolov avatar
    2566 posts

    Posted 04 Apr Link to this post

    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
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
Back to Top
UI for ASP.NET Ajax is Ready for VS 2017