Guriddo » Topic: Gets painfully slow with greater number of columns

Gets painfully slow with greater number of columns

Guriddo
Gets painfully slow with greater number of columns

This topic has 8 replies, 4 voices, and was last updated 13 years, 11 months ago by biajee.

Creator

Topic
August 23, 2011 at 5:18 pm #78912

kdorff
Participant

Hi,

We've been using jqGrid for a while and and lots the capabilities. We're loading data dynamically to be able to support large datasets, which is great.

The major problem we're having is related to the fact that some of our tables have lots of columns. One example table I just looked at has 217 columns but only like 100 rows (although the more common case is more like tens of thousands of rows). When the number of columns is relatively high like this the performance becomes really bad, even on pretty fast machines and on slow machines it is practically unusable.

Additionally, when the number of columns is high, when I try to use my column-selector, generally listing the columns to select isn't too slow, but when you apply your changes it can take a very, very long time to the point where the Javascript engine asks if you want to abort the script.

I realize that so many columns maybe outside the realm of realism for the design, but I was wondering if there was something I could to do improve things? These tables load data dynamically, which I mentioned before. They each have the input box at the top so I can search on any column and each column is sortable.

Any thoughts on this?

Thanks,
Kevin
Creator

Topic

Viewing 8 replies - 1 through 8 (of 8 total)

Author

Replies
August 23, 2011 at 5:41 pm #98673

OlegK
Participant

Hi Kevin,

all problems what you describe can be combination of design, implementation problrms together with the jqGrid problems. If you would provide the corresponding testcase (HTML and JavaScript code with the testdata) I could try to look at the problem.

Best regards
Oleg

August 23, 2011 at 11:04 pm #98676

kdorff
Participant

As my data is loaded dynamically from the database, what I created just loads data into an array and displays that. You can specify the # of rows and columns and it populates with dummy data. I have it set to 250 columns and 300 rows. At even a modestly high column count it becomes very, very sluggish. Scrolling with the wheel is less obviously sluggish but scropping by moving the scrollbar's thumb becomes unresponsive. The column-chooser at moderately high column count will display quickly and let you choose the coumns, but applying the choice of columns becomes painfully slow (to the point where it appears to be not doing anything).

The archive of my code can be found

December 7, 2011 at 7:24 pm #99166

kdorff
Participant

Hi Oleg or others,

I was wondering if you had a chance to look into this issue?

Thanks,

Kevin

December 7, 2011 at 11:06 pm #99168

OlegK
Participant

Hello Kevin,

you should use data parameter of grid instead of addRowData. Looka at the modified demo. Other demos this and

December 7, 2011 at 11:55 pm #99170

kdorff
Participant

Hi Oleg,

I am thinking you missed the point of my sample and previous discussion. Your two examples might work well with lots of rows but the number of columns you showed is very small. We are loading the data dynamically using the scrollbar and not having any problems with this.

With a limited number of columns, as shown in your example, it does work well. Even a huge number of rows (some of our results are a million or more rows), jqGrid works like a champ. But even with a limited number of rows, when the number of columns gets large, the whole thing gets very, very, very slow.

Theoretically, I agree, I'd love to not show the user 200 columns but in some cases it is necessary. Our grid is completely filterable and the columns are chooseable. We present the users with the result data, they filter the data, they choose what columns they want, and then they have meaningful data. Often, they aren't looking at ever cell, they are filtering a few cells, seeing the number of results, and then exporting the data to do analysis in a 3rd partly took like JMP. So no, they aren't inspecting 200 columns times a million rows individual cells, they are looking at the sorted, filtered results and then doing analysis of the individual cells elsewhere.

I saw the addition of column groups in 4.2, and the best case would be to be able to show/hide whole groups of columns based on some UI. Right now I have a column chooser, but a group chooser would be even better and is something that is on my to try to implement list, we'll see how that goes sometime in the future.

But, if there is something I can do or that can be done to improve speed when the number of columns gets large, that would make the user experience better…. (something other than not presenting most of the columns).

Kevin

December 8, 2011 at 12:49 am #99171

OlegK
Participant

Hello Kevin,

I am not sure what you wait from me. I shown you that you can improve performance in you would use data parameter instead of addRowData. Your original example used the column chooser in not correct way (complare its look of your example with my and verivy includes CSS and JavaScripts.)

The problem is you have very exotical requirements so you should solve some problems yourself. The pertofmance in my modified example is in my opinion good enough. Paging work under 1 sec on my computer. If I increase the number of rows from 300 to 3000 with the same number of columns (see here) the grid still make sorting and paging under 1 sec on my computer.

If you would implement server side paging and sorting you can have much more better performance. So I don't really see any hard performance problem. Mostly I see the problem in visibility. With speaking abstractly with common grid having 200 column I can't give you any other advices.

In one my real project which I implemented for one my customer I used jqGrid with about 35 column. In the case the most columns was checkboxs. So I used rotated column headers (see here an example). It reduced dramatically the width of the grid and the need to scrol it. Additionaly for all pages where many columns was needed be shown I used some applicaton oriented filters. So selecting some items in mostly two dependend select elements the user can choose the view on the data which corresponds the the business case. So the number of columns was small enough. Additionally I made on the server “pre filtering”. I verified whether in some column all the rows contains unchecked values. In the case displaying of the column will gives for the user no information. So the server send to the client additionaly to the data the list of columns which don't need be displayed and the client code hides there on the client side.

All above are examples which one can do in the real situation. So you should analyse your problem and find the corresponding way for the situation which you has.

Best regards
Oleg

January 31, 2012 at 6:25 pm #99445

Seb@
Participant

Hi,

I also have a problem with the column chooser, very slow to display result after choosing column to add or remove. I have noticed the

August 10, 2012 at 2:01 am #100053

biajee
Participant

I came up with a get around. To create your own column chooser and unload and re-create your grid like my answer here. The thing is I always maintain a my own copy of grid data so to re-create the grid, I don't have to go through another http request.
Author

Replies