Free Liberator

Performance of Grids for Streaming Data

by Martin TylerDecember 21st, 2007

One common application of Comet is displaying financial data in a grid, but how well do grids perform when handling streaming data? I’ve tested a number of different grid implementations to find out. A grid widget is something that can display rows and columns of data. This is commonly used to display a portfolio or stock list in financial applications. Each row represents a stock or other kind of instrument and each column represents a field of data, such as the last traded price or volume.

Grid Widgets

There are many Ajax tool-kits available that have implementations of grid widgets and these vary in what features they provide. Many allow advanced client-side configurability such as adding, removing and resizing columns or sorting the data based on a specified column. They also provide some styling to match other widgets being used to give a consistent feel to an interface.

Flex is another technology. It allows GUI applications to be written that run in most browsers within the Flash plug-in. Flex also provides a grid widget with similar functionality to some of the Ajax grid widgets. Although Comet is usually associated with Ajax clients I felt it was interesting to include the Flex grid in the tests discussed below.

Streaming Data

Some, or maybe all, of the grid widgets available have paid no attention to updating the contents in real-time. Most seem to have an architecture based on the Model-View-Controller pattern, where a model represents the data in the grid, but some handle updating cells in a different way. Internally, however, some implementations are not optimised for updating cells and make it difficult to style cells individually which is a common approach to representing an updated value in a cell.

Tests

I have recently performed some tests on various grid implementations. This is not meant to be a comprehensive set of tests covering all possible grids, but just enough to give an idea of how things stack up and what the trade offs are.

The following implementations were tested:

  1. A basic HTML Table
  2. HTML Table

  3. A Flex DataGrid using a native streaming implementation
  4. A Flex DataGrid using a JavaScript streaming implementation bridged into Flex (the appearance of the two Flex DataGrids is identical)
  5. Flex DataGrid

  6. A Dojo Grid
  7. Dojo Grid

  8. A Yahoo UI DataTable
  9. Yahoo UI DataTable

The tests are not all completely fair because of differences in the way some implementations work, but some conclusions can still be drawn from the results.

Each of the five implementations were tested with 10, 20, 30, 40 and 50 rows of data, each row updating once every second on average. In one set of tests a maximum of 25 rows are visible and in the other set of tests all rows are visible.

Results

Ajax Grids

Ajax Grids Results

As expected, the Ajax grids did not perform as well as the basic HTML Table implementation, but they obviously provide more functionality. Interestingly, the Yahoo UI DataTable performs much better on Firefox and gets close to the performance of the basic HTML Table.

These implementations did not benefit from non-visible rows—the CPU still increased linearly. The HTML Table and Dojo Grid were just placed in a scrollable div so this was not a surprise. The Yahoo UI DataTable allows a height to be set via CSS, but did not take advantage of this with regard to performance.

With all rows visible the results are similar, as expected.

Flex Grids

Flex Grids all rows visible

Flex Grids max 25 visible rows

The Flex DataGrid’s major bonus is that it uses no extra CPU to render non visible rows, because it just doesn’t render them. So the CPU just flattens off and it doesn’t really matter how many rows you add. In these tests I pushed it up to 1000 rows and it only used 50% more CPU than at 25 rows. Obviously there is a component of the CPU related to message parsing etc. which is why the CPU does grow, but it is insignificant compared to rendering.

With all rows visible, a better comparison can be made. The Flex DataGrid with native streaming uses more CPU than the HTML Table for low numbers of rows. However, the slope is better and at 50 rows the Flex DataGrid uses less CPU and would probably continue to have the edge over the HTML Table if more rows were added.

The Flex DataGrid being fed by JavaScript uses a lot more CPU and the slope is closer to that of the HTML Table.

Browsers

The tests were all done on a 1GHz Windows XP machine, using Internet Explorer 7 and Firefox 2. There was not a big difference between the browsers in any tests other than the Yahoo UI DataTable, which performed considerably better under Firefox.

Conclusions

For applications serious about high frequency data in grids, the current crop of Ajax grid widgets are probably not the best place to look. However, they do provide decent functionality and creating real-time grids with them is fairly easy, so for low frequency data they could fit well. Updating individual cells styles appeared to be problematic with some implementations.

The Flex DataGrid uses a lot more CPU for low numbers of rows, but appears to scale better for higher frequency data. Flex, by default, scales very well for non visible data, which is a very nice feature.

Note that the per-row frequency throughout these tests was 1 update/second. I believe the CPU used is mainly a function of overall update frequency, and in these tests the frequency was controlled by changing the number of rows. A future test could keep the number of rows constant and change the update frequency from the source of the data instead.

Also note that even the lowest frequency test is 10 updates/second, which is very high for most applications, so do not be put off using the Ajax grid widgets if your application does not require high frequency data.

Caplin Grid

At Caplin we deal with customers handling some very high frequency data. Due to the performance experienced in the above tests we developed our own grid component as part of the Caplin Trader product which aims to handle high update rates and off screen data as efficiently as possible. I will post some test results for this grid in the future. Caplin plans on releasing this grid as a standalone Ajax component some time next year.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]
Orbited

5 Responses to “Performance of Grids for Streaming Data”

  1. Comet Daily » Blog Archive » Integration of Ajax and Comet Libraries Says:

    [...] a previous article of mine on the performance of grids for streaming data, I implemented examples using both Dojo and Yahoo UI grids with streaming data. The grids were [...]

  2. s.w.pollu Says:

    hi,would you like to send me the code of dojo grid demo.Thanks in advance!

  3. Martin Tyler Says:

    You can download Liberator from http://www.freeliberator.com or view examples/demos online. The Dojo grid used for these tests is one of the examples

  4. Seth Hodgson Says:

    Great post Martin!

    Have you plotted the client memory footprints across the various libraries for these tests? It seems like that could be a more useful metric than CPU for web clients receiving streaming data, especially if they’re left running for any substantial length of time.

    Best,
    Seth

  5. Comet Daily » Blog Archive » Grid Performance - Round 2 Says:

    [...] such as responsiveness of user interaction and speed of rendering. This article is a follow-up to Performance of Grids for Streaming Data and covers Firefox [...]

Leave a Reply



Copyright 2010 Comet Daily, LLC. All Rights Reserved