SmartClient Version v9.1p_2014-05-27/Enterprise
Chrome 35, FireFox 29.0.1
We have a ListGrid that displays stock quotes. The grid is linked to a server-side custom data source which delivers initial information from a legacy system using custom communications protocol. (not using SQL, Hibernate or JPA)
The grid is than updated using the same pattern demonstrated here: http://www.smartclient.com/#portfolioGrid, the only difference is that we do not use your messaging module, but a WebSocket connection so the sample changes like this:
Than we apply hilites on the grid using the following code:
We also use partial rendering - only visible rows and visible columns are painted.
The DataSource has "cacheAllData:true" property.
The updates are applied in batches every 2 sec.
This works well for relatively small number of codes, up to about 100-200 rows.
When the number of rows increases, the grid and the entire browser becomes slow and unresponsive. At about 500 rows, the grid and the browser freezes every 2 seconds - when the next batch of updates arrives. The number of changed cells has little or no effect on the delay if there is at least one changed visible cell.
Profiling the application shows that at this point 60% of the CPU time is used inside ListGrid.applyHilites().
If we remove the hilites, than we can go up to about 2000 rows at which point the bottleneck becomes ResultSet.findAll(...)
And here are the questions:
1. How to improve the hilites performance ? In your portfolio example you use getCellCSSText to apply hilites. Is that faster than applying hilites using the corresponding ListGrid property ?
2. We understand that using 2000+ "live" rows, cached on the client side, is an extreme case :), but is there something we can do in order to improve ResultSet.findAll performance? The "CODE" field we use in the code example above is not a primary key, because we allow duplicates in the grid.
Chrome 35, FireFox 29.0.1
We have a ListGrid that displays stock quotes. The grid is linked to a server-side custom data source which delivers initial information from a legacy system using custom communications protocol. (not using SQL, Hibernate or JPA)
The grid is than updated using the same pattern demonstrated here: http://www.smartclient.com/#portfolioGrid, the only difference is that we do not use your messaging module, but a WebSocket connection so the sample changes like this:
Code:
scket.onmessage(data){
var subs = subscribers; // this is a global array of all ResultSet(s) displaying portfolio data
for(var index=subs.length-1; index>=0; index--){
var recordset = subs[index];
var rows = recordset.findAll("CODE", data.CODE);
if(rows !== null){
for(var i=rows.length-1; i>-1; i--){
isc.addProperties(rows[i], data);
}
recordset.dataSource.updateCaches({
data: rows,
operationType: "update"
});
}
rows = null;
}
}Code:
watchlistGrid.setHilites([
{
criteria:{
_constructor:"AdvancedCriteria",
fieldName:"TRADE",
operator:"lessThanField",
value:"PTRADE"
},
fieldName:["TRADE"],
textColor:"#ff0000"
},
{
criteria:{
_constructor:"AdvancedCriteria",
fieldName:"TRADE",
operator:"greaterThanField",
value:"PTRADE"
},
fieldName:["TRADE"],
textColor:"#00c000"
},
{
criteria:{
_constructor:"AdvancedCriteria",
fieldName:"TRADE",
operator:"greaterOrEqualField",
value:"CLOSE"
},
fieldName:["CODE"],
// icon:"watchlist/a_green_up.png"
icon:"data:image/png;base64,......."
},
{
criteria:{
_constructor:"AdvancedCriteria",
fieldName:"TRADE",
operator:"lessThanField",
value:"CLOSE"
},
fieldName:["CODE"],
// icon:"watchlist/a_red_down.png"
icon:"data:image/png;base64,......."
}
]);The DataSource has "cacheAllData:true" property.
The updates are applied in batches every 2 sec.
This works well for relatively small number of codes, up to about 100-200 rows.
When the number of rows increases, the grid and the entire browser becomes slow and unresponsive. At about 500 rows, the grid and the browser freezes every 2 seconds - when the next batch of updates arrives. The number of changed cells has little or no effect on the delay if there is at least one changed visible cell.
Profiling the application shows that at this point 60% of the CPU time is used inside ListGrid.applyHilites().
If we remove the hilites, than we can go up to about 2000 rows at which point the bottleneck becomes ResultSet.findAll(...)
And here are the questions:
1. How to improve the hilites performance ? In your portfolio example you use getCellCSSText to apply hilites. Is that faster than applying hilites using the corresponding ListGrid property ?
2. We understand that using 2000+ "live" rows, cached on the client side, is an extreme case :), but is there something we can do in order to improve ResultSet.findAll performance? The "CODE" field we use in the code example above is not a primary key, because we allow duplicates in the grid.