We're using PrimeNG's Turbo Table with dynamic columns to display 1000 records per page.Both server-side pagination and sorting are enabled. This works well in Chrome but it is staggeringly slow in IE during sorting, pagination or updating all the records. Once the server response is returned in ~9s, IE freezes for 2 min and then displays the data. Also, the table uses ngSwitch to determine the column content, for instance, some columns display icons, some display a text area and so on.
Enabling prodMode has helped improve the page load significantly and this is comparable to Chrome now, however we still have performance issues while sorting, pagination and updating the records.
We've tested the performance by removing ngSwitch and observed a slight improvement - a 10s reduction. However, we require the ngSwitch functionality, so removing it really isn't an option, unless there's an alternative we can use. Anyhow, it doesn't quite solve our problem.
Appreciate any help please!
It can be possible that IE needs more time than any other latest browsers, especially in the situation that you need to display 1000 records which is not a small amount. I don't know if it is possible for your-case to load less records per time. If possible, you could find a balance between the load time and records amounts in IE.
Without any sample code, we can only provide some general suggestions. In this situation, I can only suggest you to use F12 developer Performance tools to analyze UI performance, and use F12 developer Network tools to check the request spend time. If the Dev Tools doesn't work well in your IE, you could also use Windows Performance Toolkit to analyze the website performance.
Related
Maybe someone can shed any light, personal experience or reference to official documentation.
Suppose, I have a Google Spreadsheet, which I connected to other Spreadsheets by using IMPORTRANGE. I noticed that my receiving Spreadsheet started loading slower than normal. Are there any tricks for optimizing the loading speed? For example, does it make any difference if I:
Use IMPORTRANGE less frequently by loading the data (let's say, once) to a separate tab, and then query that tab internally from within the same spreadsheet?
or
Use IMPORTRANGE frequently in multiple cells and run Query for each cell individually, and avoid having a large dedicated tab that gets all the info first?
Use IMPORTRANGE less frequently by loading the data (let's say, once) to a separate tab, and then query that tab internally from within the same spreadsheet?
definitely the right approach to gain performance speed
I am working on an MVC project where I use jqGrid for ASP.NET MVC. However I am told by that the pure-jquery-client-side version (jqGrid) is better in performance. Is this true? To me they both seem to be doing the same stuff, just that the code is in different places- all the bulk work is still done using ajax.
any advise would be appreciated.
EDIT-
most places I use the grid has less than a 100 rows,page size 30,about 10-12 columns, mostly strings and dates. Only one page I use a grid with 500 rows but that will be used rarely.
I don't think that you should rewrite your existing code, but I can agree that in case of usage less then 1000 rows of data the usage of loadonce: true is real alternative.
The design of jqGrid is oriented on server side sorting, paging and filtering/searching. So most users who start to use jqGrid in version less then 3.7 have already good implementation of backend. SQL Server with native code should be sure more quickly as JavaScript code were originally designed as interpreter language. On the other side current versions of web browsers contain quickly JavaScript engine. Every new version improve more and more performance of JavaScript.
It could be important for the user the total time of the paring, sorting or filtering operation. It includes the round trip time to the web server. One can better do exact measure in productive environment to compare performance of local grids with grids with pure remote datatype ("json" or "xml" without usage of loadonce). The rough rule which I use myself is:
if the number of rows under some 1000 rows I use loadonce: true and so client side paging, sorting and filtering of data
if the total number of rows larger as 10000 I use always server side paging, sorting and filtering
Your environment (network, Round trip time to the server and so on) could be other. So the edge when you should better user client side holding of data and when server side holding could be other. Nevertheless the usage of loadonce: true could be really very effective in the practice.
I personally don't use commertal version of jqGrid which you referenced. So I have to write backend side myself. In case of usage of loadonce: true the server code is very simple. It's easy to debug and to maintain.
I am using GWT 2.4. There are times when I have to show huge amount of records for example: 50,000 records on my screen in a gridtable or flextable. But it takes very long to load that screen say around 30 mins or so; or, ultimately the screen hangs or at times IE displays an error saying that this might take too long and your application will stop working, so do you wish to continue.
Is there any solution to improve gwt performance?
Don't bring all data at once, you should bring it in pages, as the comments suggested here.
However, paging not be trivial , as it might be that during paging your db is filled with more entries, and if you're using some sorting algorithm for the results,
the new entries might ruin your sorting (for example, when trying to fetch page #2, some entries that should have been on the first page are inserted.
You may decided that you create some sort of "cursor" for paging purposes and it will reflect the state of your database at the point you created it, so you will ignore entires that are entered during traversal between pages.
Another option you may consider, as part of paging is providing only a small version for each record - i.e - only the most important details, and let the user double click if he wants to see the whole details for the record - this can also provide you some performance improvement within each page.
I have a question regarding capabilities jqGrid. We want to turn paging off and load all the data on the client side without implementing virtual scrolling (paging turned off as well). How many records can the jqGrid handle realistically as we have been trying to load 50,000 records * 20 columns and it seems to blow up (Note: Virtual Scrolling turned off and Paging turned off)
I don't think that it's good idea. No user are able to look through 1 million cells. So you want to send 99,9% (or more) unneeded data to the client. What you really need is implementation of the subject oriented filtering of the data.
The performance of the grid will be mostly depend from the JavaScript engine of the web browser which you use. Nobody can get you common recommendation for IE6 and Chrome 19 because of very different JavaScript performance.
In any way I am sure that you have to implement paging, sorting and filtering on the server side. I think it's really required in case of 1 million cells of data.
Large datasets, millions of records, need special programming to maintain speed in DBGrids.
I want to know if there are any ready-made components for Delphi (DBGrids) that do this automatically?
EDIT For Example: Some databases have features such as fetch 1st X records (eg 100 records). When I reach the bottom with scrolling, I want to auto fetch the next 100. Conversely when I reach the beginning, I want to fetch the previous 100. I know I can program this, but it sure is possible to propagate that feature to a DBGrid control where the DBGrid does the buffering. It will save quite a bit of programming - you simply have to set the "buffer size" so to speak.
You might want to take a look at the wonderful (free, open source, dual licensed as MPL 1.1 and GPL thus usable in closed source apps) Virtual TreeView and its user-supplied descendants (scroll down the page to find those.)
Edit to reflect the question's edit: Virtual TreeView not only allows you to handle millions of nodes without keeping them in memory, but that is in fact the preferred way of using it. You supply the data through event callbacks when it's needed, and you can tell the tree to cache that data (or not.)
Oh, and of course it also has a grid / report mode where it can function as a table (just set the GridExtensions property to True.)
I would have a look at Developer Express QuantumGrid Suite. (#birger: you just were a tick faster ;-) ) So I'm not just duplicating the answer, some elaboration:
The DevExpress Grid uses a data controller that has several modes to controll the data bound to the grid. One of these is exactly what you are looking for:
Grid Mode
When using Grid Mode, only a fixed
number of dataset records is loaded
into memory. Because only a limited
set of records are retrieved from the
dataset, automatic sorting, filtering
and summary calculations are disabled
in Grid Mode (must be controlled
manually instead). By default, this
mode is disabled and the
ExpressDataController loads all
records in a dataset.
It does have some drawbacks, which seem pretty obvious: you cannot make a summary, sort, or filter if you do not have all records at hand.
NextGrid is light, fast and nice looking grid for Delphi
http://www.bergsoft.net/component/next-grid/features.htm
HANDLING LARGE AMOUNT OF CELLS WITHOUT LOOSING SPEED
NextGrid can handle very large amount
of cells without losing speed. Speed
of adding, modifying and deleting data
doesn't depend of the amount of cells.
In NextGrid demo you can see how fast
NextGrid work with 100,000 rows and 10
columns = 1,000,000 cells
I think the DevExpress Quantumgrid supports this very good.
sorry, I just saw your comment to Neftalí
if you would to bring 100 record per time, and then fetch the next 100, this work related to database access components, look at devart components, they are offer direct access components to most used database, and they have the feature you are asking about and more:
http://www.devart.com/products-vcl.html