Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Grid performance

  1. #1

    Cool Grid performance

    I have same old issue with Grid and Tree performance. Its too slow for over 50 rows/nodes. I see lots of ppl saying that it doesnt make sence to display lots of rows. One guy needed to display 3600 rows and ppl suggested to use paged view. I don't think those are solutions but rather workarounds. We have website that uses our own Grid and Tree controls and able to initialize 4000 or 5000 rows/nodes in less then a second (of course Im not counting loading of data itself). Sorting and scrolling is no issue at all (speedwise).

    I like Ext.Grid and Ext.Tree since it looks sexier. So, here are my points for the author on improving Grid:
    1) don't build HTML table for the WHOLE set of data but only for the visible part
    2) as result of 1) you need your own vertical scrollbar

    Cheers.

  2. #2

    Default fter bit of viewing

    Just spend some time digging into source code of GridView and Im no longer surprised why its so slow to build grid even with 10 rows. Root of the evil is DIVs. Basically every cell in the Grid results in creation of 2 DIVs and approximate formula for total number of produced DIVs is: 20+2*<number of cells including header cells>. So, if you have 10 columns and 100 rows or 100 columns and 10 rows your browser will endup building around 20+2*1000=2030 DIVs (plus header DIVs)!
    Anyone who deals with JavaScript knows that any element creation (and DIV in particular) is expensive operation.
    If that is same logic for the Tree then it also explains slow initializing and 100% CPU spike during init.
    Question: why so heavy on the DIVs? Why not use native TD (which is faster to create for browser)?

    Cheers.

  3. #3

    Default Performance and limitations

    Quote Originally Posted by aresot View Post
    Just spend some time digging into source code of GridView and Im no longer surprised why its so slow to build grid even with 10 rows. Root of the evil is DIVs. Basically every cell in the Grid results in creation of 2 DIVs and approximate formula for total number of produced DIVs is: 20+2*<number of cells including header cells>. So, if you have 10 columns and 100 rows or 100 columns and 10 rows your browser will endup building around 20+2*1000=2030 DIVs (plus header DIVs)!
    Anyone who deals with JavaScript knows that any element creation (and DIV in particular) is expensive operation.
    If that is same logic for the Tree then it also explains slow initializing and 100% CPU spike during init.
    Question: why so heavy on the DIVs? Why not use native TD (which is faster to create for browser)?

    Cheers.
    I think the problem is even worse than you describe, though the factors are different in Ext 2.0.

    Grids are rendered in HTML using a DIV for the whole grid containing a DIV for each row, and then each row DIV contains a TABLE and each cell contains one DIV. The problem is not only the overhead of building all those DIVs and separate TABLEs, but the fact that columns must be separately sized for each row. No wonder there is no auto-sizing of columns based on the cell contents - something TABLEs provide for 'free'.

    ExtJS is the best framework I have seen, but for me, this is a show-stopper.

    This is crazy, and unnecessary. Why not just use a normal table for the grid and let the table do the alignment of columns in rows?

    If the reason is to provide frozen header rowss and frozen columns, this can be implemented with a single parallel table for the frozen header rows, and a single parallel table for the frozen columns.

    If the reason is to provide hierarchical rows, where the subrows don't have the same columns, this can be implemented with an extra row that spans all the columns. Is there any other reason for all this overhead and limitation of features?

  4. #4
    Sencha User
    Join Date
    Mar 2007
    Posts
    7,854

    Default

    Given the multiple iterations that the grid has gone thru to improve performance and work consistently x-browser, I would think that changing the layout as you suggest isn't going to improve things much. The fact remains that creating DOM elements is slow, especially on IE6. Have you compared the performance of the 1.x grid with the one in 2.0?

  5. #5
    Sencha User jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    DC Area =)
    Posts
    16,364

    Default

    It's a world of difference if you ask me.

  6. #6

    Default

    I just started looking at ExtJs a few days ago, and am seriously impressed. But then I looked a little deeper, like at the actual dom structure generated by the grid, and immediately noticed the same issue described in this thread - each row in the grid being a separate div + table.

    I really would like to hear if there is some compelling reason for this. Does this provide some key functionality or stylistc control that can't be achieved otherwise? The project that I would really like to use ExtJS for is going to have some fairly dense grids, and I'm concerned that this could be a crippler.

    Does this get discussed alot? I can see how it might be a topic of real debate, but I'm new here.

    Thanks

  7. #7
    Sencha User gimbles's Avatar
    Join Date
    Jun 2007
    Posts
    34

    Default

    I'd think you would see more controversy regarding the grid. I see huge slowdowns when rendering grids with 6-7 columns and 60+ rows. It's come to a point where I've been weighing how much time I'll lose taking apart the grid control down to only exactly what I need and then rebuilding it without all the divs.

    And this is 2.0 mind you.

  8. #8

    Default 2.0 grids are slow - better luck with 3.0.

    Quote Originally Posted by gimbles View Post
    I'd think you would see more controversy regarding the grid. I see huge slowdowns when rendering grids with 6-7 columns and 60+ rows. It's come to a point where I've been weighing how much time I'll lose taking apart the grid control down to only exactly what I need and then rebuilding it without all the divs.

    And this is 2.0 mind you.
    Hoping to raise the controversy level myself. I gave up on ExtJS grids and I am using YUI datatables for now, which use regular HTML tables, though they render them by using explicit DOM calls for each element rather than inserting the generated HTML text, so it could be even faster if done "right".

    And it is not only the performance, but the autosizing feature based on cell content that I miss. ExtJS 2.0 stopped supporting the autosizing because they way they manually resize everything, it would hit performance that much more.

    <rant>I don't know where this bias against HTML tables came from, but I hope the purists wake up soon. Tables provide 2D alignment that, without them, you have to reimplement just like they already do. The proposed CSS TABLE-like style properties would merely allow you to make other elements work just like tables. So what? With client-side frameworks such as ExtJS, we are dynamically rendering HTML for display, choosing elements that work effectively with the styles we want. </rant>

    I had a try at replacing the ExtJS grid templates, but didn't make much progress. I would be willing to work with others on this.

  9. #9

    Default

    Grid performance is a big issue...

    Please, is possible to listen the opinion of the ExtJS team?

  10. #10
    Ext User
    Join Date
    Feb 2008
    Posts
    12

    Default

    Hi, just want to ask if any progress has been done about grid slowness problem?

    I confirm that from cca 50 records GridPanel starts to be slow (rendering?) eg. sorting records action. I have one Panel (accordion layout) containing two panels. First have grid inside and animation while clicking between those two panels is slow too (when animCollapse is set to false, it's little faster).

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •