Performance

I am using the latest demo version to determine whether or not your grid will work for our (extremeley data-intensive) application.

I have converted a table of data with the following specs:

13 columns
466 rows
ffx 1.5 on Win XP (2Gig RAM)

The resulting grid is unusably slow. It loads slowly (ffx prompts me to "stop script, or let it continue") and scrolling through data is painfully slow.

From what I've read, I'm using the faster loading object. My code is something like:

var myData = [
[
"<a href=\"someURL">CYTEC INDUSTRIES INC</a>",
"<a href=\"someURL">CYT 5.500 10/01/10</a>",
"CHEM",
"0.178%",
"71.3",
"23.6",
"0.9",
"0.040",
"0.000",
"0.000",
"0.090",
"0.000",
"0.000"
],
etc... for 466 rows
];

MoversTable = new AW.UI.Grid;
MoversTable.setCellText(myData);
MoversTable.setHeaderText(myColumns);
MoversTable.setId("myGrid");

MoversTable.setVirtualMode(false);
MoversTable.setRowCount(<%=rowCnt%>);
MoversTable.setColumnCount(13);
document.write(MoversTable);

I've tried a virtual mode of both true and false. False results in script warnings on load, and scrolls much too slow. True gets rid of the initial script error, but it just takes too long for the data to load after scrolling.

So what's the absolute fastest way for me to load and display data? Am I dong something wrong, or is this in fact just too much data? It just doesn't seem like a 13x466 table should overwhelm this thing.

Switching off virtual mode only makes sense for <100 rows, otherwise it is just too much time to render all cells.

If you keep virtual mode on - then it does not really matter how many rows you have, this example has 50,000:

http://www.activewidgets.com/general.demos/virtual-mode.html

Does this one works ok? When you say 'too long for the data to load after scrolling', how much is 'too long'? I would say normal delay should be around 0.5-1 sec for 13 columns.

Alex,

Thanks for the reply. Things seems to be working better now. I've been messing with this quite a bit and everything (all processes on my machine) slowed. A reboot sped up the grid by some 200%. We may be making the leap to your product, so I just need convincing that there's nothing in the grid that will cause performance to degrade over time... that will cause our users to have to restart ocassionally?

thanks

The performance drop (sometimes as large as 500-1000%) is quite common for memory leaking code and when you reload the page multiple times to accumulate them (this is what we always do during the development :-).

AW itself is designed to eliminate typical reasons for IE memory leaks and I guess it should also work in FF (so far I am not aware of memory leaking bugs in either IE or FF). However this is a tricky matter and requires you to keep your code clean as well :-)

Agreed! I'm more than willing to accept the leak is somewhere in my code (it happens, unfortunately!) .

Back to evaluating... thanks for the info.

More performance questions:

A few weeks back I bought the grid and we've been reasonably happy with how it handles very large datasets. Ironically, my users are not happy with small datasets (between 100 and 500 rows). A few hundred rows is too much data when virtual mode is off (CPU gets pegged at 100% and whole table lags when scrolling), yet when virtual mode is on the scrolling is as slow as 10,000 rows. (I know... I want my cake and eat it too).

It think I know the answer to this, but I need a way to have 400 rows of data load fast and be responsive to scrolling. Any recommendations? I'm building all this data via XML - is using an array instead going to help? In general we're not too concerned with initial page-load time. The big concern is responsiveness. As it stand now, the virtual mode with 400 (or so) rows is just too slow and unfortunately I'm having to roll back to old tables.

Again, I know I may be asking the impossible, but any thoughts would be appreciated.

If you compare performance of your page with /examples/new/virtual.htm - is there much difference? I would expect the grid to repaint rows after scrolling to an empty area in virtual mode in 0.5-0.8 sec (including 0.2 sec. inactivity timeout). This is noticeable but probably not 'terribly slow' (?)

Here is the code which measures the repaint time -

var obj = new AW.UI.Grid;
    obj.setCellData("cell");
    obj.setHeaderText("header");
    obj.setColumnCount(10);
    obj.setRowCount(1000);
    document.write(obj);

    var d1, d2;

    obj.onScrollTopChanged = function(){
        d1 = new Date();
    }

    obj.onVirtualTopChanged = function(){
        window.setTimeout(function(){
            d2 = new Date();
            window.status = "Rows repainted in " + (d2-d1-200) + " ms";
            // minus 200 ms inactivity threshold
        });
    }

I have 120-150 ms in IE and 200-250 ms in FF1.5 on 2.7GHz machine.

If you have much worse than this with the similar grid size - then something is wrong.

I would not recommend switching off virtual mode. The performance limit here is around 0.2-0.5 ms per cell, so you'll have at least 2-3 sec rendering time plus all scrolling/selection actions will be very slow (with 20,000 spans required to render 400x10 grid). At least use AW.Templates.Cell (most simple one) instead of the default AW.Templates.Text (but you will loose vertical alignment).

URGENT - NEED HELP.

I have compared my scrolling performance to the virtual-mode.html link mentioned above. I found my 5000 row report to take about 5 seconds to refresh the scrolled page. 10000 rows takes 10-11 seconds. Yet the 50000 rows in the sample takes much much less.
I found the difference to be that all my data from the 5000 rows is stored in the js array on the page. The example dynamically creates data within the function and does not store an array. I took my code and replaced the data source to match the function in the example and achieved similar performance.

How do I get this performance using the array???? This is being used in production and my user is complaining about the slow scroll. Please help.

I don't see any significant difference in scrolling page repaint time when I use actual 10'000x10 array instead of the generated content as in virtual.htm example. The repaint time is still below 1 sec in IE6 (i.e. 0.5-0.8 sec). It seems to increase to 1.0-1.5 sec for 50'000x10 array. I think the the slow scrolling should be due to something else, not just because of the javascript array.

I am using 24 columns. Also, increase the size of the data in the columns. That may make a difference. But I am 99% sure of this. The way I tested this was by removing all pieces of code 1 by 1 to see what was impacting the performance. Nothing had an impact until I replaced the array with the function. I will verify it again and send two comparative scripts.

I am using IE 6 and without a doubt I have found the array to impact the delay of each scoll. The following script performs great:

<html>
<head>
<title>ActiveWidgets Examples</title>
<script src="../../runtime/lib/aw.js"></script>
<link href="../../runtime/styles/xp/aw.css" rel="stylesheet"></link>
</head>
<body>
<style>

/********************************************************************
/////////////////////////////////////////////////////////////////////

C S S

/////////////////////////////////////////////////////////////////////
********************************************************************/

/********************************************************************
Grid
********************************************************************/

/* you may skip grid id (#myGrid) in all other rules
- if the rule applies to all grids
- if you have only one grid on your page */

#myGrid { width: 400px}

/********************************************************************
Rows
********************************************************************/

#myGrid .aw-grid-row {height: 20px; border-bottom: 1px solid #ccc}
/* #myGrid .aw-row-1 {color: blue} */

/* Alternate row colors */
#myGrid .aw-alternate-even {background: #fff;}
#myGrid .aw-alternate-odd {background: #eee;}

#myGrid .aw-alternate-even .aw-column-1 {background: #eee;}
#myGrid .aw-alternate-odd .aw-column-1 {background: #ddd;}

/* Highlight on mouseover, mousedown */
/* #myGrid .aw-mouseover-row {background: #ccc;} */
/* #myGrid .aw-mousedown-row {background: #999;} */

/* #myGrid .aw-mouseover-row .aw-column-1 {background: #bbb;} */
/* #myGrid .aw-mousedown-row .aw-column-1 {background: #888;} */

/* Selected rows */
#myGrid .aw-rows-selected {background: #316ac5;}
#myGrid .aw-rows-selected .aw-column-1 {background: #316ac5;}


/********************************************************************
Columns
********************************************************************/

#myGrid .aw-column-0 {width: 50px; border-right: 1px dotted #ccc;}
#myGrid .aw-column-1 {width: 150px; border-right: 1px dotted #ccc;}
#myGrid .aw-column-2 {text-align: right}
#myGrid .aw-column-3 {text-align: right}
#myGrid .aw-column-4 {text-align: right}

/********************************************************************
Cells
********************************************************************/

/* #myGrid .aw-row-2 .aw-column-1 {color: red; font-style: italic} */

/* Highlight on mouseover, mousedown */
/* #myGrid .aw-mouseover-cell {color: red;} */
/* #myGrid .aw-mousedown-cell {background: #666;} */

/* Selected cells */
#myGrid .aw-grid-row .aw-cells-selected {background: #316ac5;}

/********************************************************************
Headers
********************************************************************/

#myGrid .aw-grid-headers {color: blue}
#myGrid .aw-grid-headers .aw-column-1 {font-weight: bold}

/* Highlight on mouseover, mousedown */
#myGrid .aw-mouseover-header {color: red;}
#myGrid .aw-mousedown-header {color: yellow;}

#myGrid .aw-header-1 {background: #def}

/********************************************************************
Row selectors
********************************************************************/

#myGrid .aw-row-selector {width: 20px; text-align: center}
#myGrid .aw-row-2 .aw-row-selector {font-weight: bold}
#myGrid .aw-mouseover-row .aw-row-selector {color: red;}

/* Highlight on mouseover, mousedown */
#myGrid .aw-mouseover-selector {background: green;}
#myGrid .aw-mousedown-selector {background: yellow;}

</style>

<script>

/********************************************************************
/////////////////////////////////////////////////////////////////////

D A T A S O U R C E S

/////////////////////////////////////////////////////////////////////
********************************************************************/


var myHeaders = ["Ticker", "Company Name", "Market Cap.", "$ Sales", "Employees"];
var obj = new AW.Grid.Extended;
obj.setSize(850, 500);
obj.setCellText(function(i, j){return j + ".abcdefghijklmno" + i});
obj.setHeaderText("header");

obj.setColumnCount(20);
obj.setRowCount(10000);

obj.onHeaderClicked = function(){return true};

document.write(obj);
</script>
</body>
</html>


HOWEVER - I now add:

var myData = [
["MSFT","Microsoft Corporation", "314,571.156", "32,187.000", "55000","MSFT","Microsoft Corporation", "314,571.156", "32,187.000", "55000","MSFT","Microsoft Corporation", "314,571.156", "32,187.000", "55000","MSFT","Microsoft Corporation", "314,571.156", "32,187.000", "55000"]
]

I repeat this row 10,000 times to make myData size = 10000. I replace

obj.setCellText(function(i, j){return j + ".abcdefghijklmno" + i});

with

obj.setCellText(function(i, j){return myData[j][i]});


THATS IT. The scroll delay goes from .5-1 second to 5-8 seconds!

Please let me know if you find the same and if there is a work around!

bump

Yes, I can reproduce the repaint speed going down with very large javascript arrays. I don't see numbers which are that bad (maybe max 2-3 sec) but that may be the difference in CPU speed etc.

What I found so far - the speed is going down even if the large array is not used as a data source but simply is present on the page -

obj.setCellText(function(i, j){return "static text"});

has the same speed as

obj.setCellText(function(i, j){return myData[j][i]});

when myData array is present and has the same size.

The critical array size seem to be around 200'000-500'000 elements and this slows down all javascript operations. I remember reading about similar problem in other places and it is believed to be general problem with IE6 javascript engine and related to the inefficient garbage collection algorithm.

I am not sure if there are really any good solutions here. IE7 seems to be much faster. Maybe switch to CSV datasource. or implement similar 'parse-on-demand' logic with js -

// row as single string
var rawData = [
"MSFT|Microsoft Corporation|314,571.156|32,187.000|...",
"MSFT|Microsoft Corporation|314,571.156|32,187.000|...",
]

// built on-demand
var myData = [];

function dataSource(c, r){
    if (!myData[r]){
        myData[r] = rawData[r].split("|");
    }
    return myData[r][c];
}

grid.setCellText(dataSource);

plus maybe some general recommendations - use setCellText (not setCellData), use AW.UI.Grid instead of AW.Grid.Extended, use AW.Templates.Cell instead of the default cell template (AW.Templates.Text).

Thanks Alex. So what you are thinking with the parse idea is that the raw data would be smaller in size since no double quotes are specified? And it is no longer 2D array. I guess that would help to some degree.

I have not used the CSV source. I'll try it. What if I put the myData array in a dynamically created .js file?

I think what matters is not the total memory size but the number of javascript objects as it somehow affects the efficiency of the garbage collection algorithm.

When the 2D array is packed into 1D strings the number of objects is reduced from 200,000 to 10,000 and this has greater effect than additional time needed for splitting the string into individual cells.

Alex,

I found that using the CSV is definitely the way to go! It seems that the size of the dataset has no impact on the scroll delay. It performs beautifully no matter what the size. Does that make sense to you? If yes, could you explain why that is?

I am going forward and changing my implementation. My suggestion is that you tell programmers that CSV is the way to go for datasets over a few hundred rows.

Thanks again for your help!

Alex,

One other question: with the CSV, is each scroll then a trip to the server? I tested this all on a laptop. When I put it on a server, would performance degrade because it has to go to the server for each scroll request?

The AW.CSV.Table object loads .csv file and splits it into rows. Then each row is splitted into the cells on the first request for cell in this row. Which means that if you scroll down all 10,000 rows page-by-page and all rows eventually will be parsed - the performance will go down the same way as with js array.

If you are using CSV source add this patch for more reliable parsing -

http://www.activewidgets.com/javascript.forum.17221.4/escape-a-comma-in-a.html

I will retest - but my initial testing showed no degrade in performance as i scrolled with 10000 rows.

Alex,

My testing reveals that the performance does not degrade. Using a CSV the scrolling delay is very good and remains consistent. I tested using 5000 rows and scrolled all the way thru. The time did not change.

What is the patch for? Looks like something to do with commas embedded in the file?

never mind - just realized that the explaination is in the link...

I use a straight JS array for an inventory control application I'm using... and other than the AJAX calls to update the database based on Grid changes taking a while (100+KB of data to get each AJAX call... need to figure out how to retrieve and update a single row to make it faster) the Grid works EXCELLENT for our 300,000 items, each with 18 columns of data ranging from integer data to item descriptions w/150 characters... that's a lot of data.

Excellent job AW!!

John,

Are you using FF or IE. Extended grid or Grid? What exactly is your scroll delay?

I spent a lot of time on this and Alex found the same result based on the script above: there is a delay in scrolling based upon the script above that is caused by the javascript array becoming large. Depending on the browser and machine capacity, the delay is probably minimized.

I'd be very interested to see if you are doing something different that improves the performance. Any chance of supplying the script that you are using?

John,

I spent quite a bit of time on this and proved out that as the javascript array gets larger, scrolling delay increases. Alex had found the same. Based on the browser and client settings, the delay probably can be minimized (for example, Alex did not experience as big a delay as I did). What browser are you testing with? Are you using the extended grid? How much memory is on your workstation? What exactly is your delay when scrolling?

I'd be very interested to hear if you have uncovered a solution or best practice that I am not using. Any possibility of supplying a sample script that you feel performs well?

Don't know why the first post I made suddenly appears. I first made a post and did not see it so I did it again....oh well.

Are there any news since joel's last post in 2006 about this performance issue.

I've dicovered aw today and I'm lovin' it, but I've just read this topic and some doubts came to my head.

I'm workin with large amounts of data from a database and I my client need good performance. What u think about aw? is it good for this?

Requirement:-
We need to display 50 columns and 300 rows in the page. Some of columns we need to hide/show based on the user input. (by clicking button)

Problems facing:
1. Grid is taking 5 Seconds to load with Virtual Mode . Most of the times it is Fluctuating between 4-7 seconds.

2. Hide/show functionality is taking more than 1 second.

Any suggestions would be appreciated.

I found that loading a grid from an in-line file (csv or xml) is usually very slow while displaying the same data from an external file is MUCH faster (up to 10 times). I tested it with FF-2.0 and tables as big as 10000 rows x 7 columns: with in-line data , the loading could never complete, from an external file the loadind completes within 3 to 4 seconds!

So ...

I have just found that changing the buffer size of the scrollable area from 20 to 40 rows (see related posts about scrolling improvement) dramatically improved the loading an in-line data. Why? no idea, but it works