Performance and User Experience

We've done the testing and now we've written the whitepapers: the performance of our Web charts and Web grids are the fastest on the market. We show you the architecture, and share with you the complete test results in our Silverlight Grid performance whitepaper, ASP.NET AJAX Grid performance whitepaper, and Silverlight/WPF Chart performance whitepaper, and jQuery Grid performance whitepaper (new!).

Below are Excerpts from our Latest jQuery Grid Performance Whitepaper

Everyone talks about user experience today – it is a key differentiator in the new economy. When most people talk about the user experience of their application, the conversation is generally focused on the aesthetic design of their application, which while important is merely one aspect of the overall user experience. Often people neglect to think about an area of user experience that can have just as strong of an impact on the overall experience of their application as the applications aesthetics – application performance!  For the whole story on our testing methodology for jQuery Grids, how we approach performance, and for a complete list of performance results, download our jQuery Grid performance whitepaper.

Why does performance matter so much in the overall user experience?

• Higher Customer Satisfaction
• Improved End User Productivity
• Resource Efficiency in Hardware and Bandwidth

For the whole story on our testing methodology, how we approach performance, and for a complete list of the performance results, download the performance whitepapers for Silverlight Grids, Silverlight/WPF Charts, ASP.NET AJAX and jQuery Grids today!!

Fastest jQuery Grid Control on the Market

The Infragistics jQuery grid control is the fastest jQuery grid available anywhere, based on the rigorous performance tests documented in our jQuery Grid performance whitepaper. We regularly test our UI components against the competition to ensure we're always delivering you the best performance possible.  Our jQuery grid control is no exception, and the test results show it is the fastest jQuery grid available anywhere!

Our test applications have used the latest public bits from our grids, as well as bits from five jQuery competing grids. Test applications are designed to ensure that we have compared "apples-to-apples"—and simulate real-world scenarios found in banks, call centers, insurance companies, etc. For comparison purposes, we use public information found on our competitors' websites.

For the purpose of this whitepaper, we quote results for the Infragistics jQuery grid control against its two closest competitors. For the purpose of anonymity, we named these competitors: "Competitor I" and "Competitor II".

Our jQuery grid control has the unique feature of being both a pure client grid and MVC grid. As a result, in addition to comparing the igGrid against the top two competitors, we compared the grid to the best MVC grids on the market today and classified them as “Competitor III”.

We note that none of our competitors include DOM virtualization—this means that their grid controls need to create DOM elements for cells that are not in the visible area of their grids.

Having said that, it is noted that we are comparing our jQuery grid control to non-virtualized grids, simply because we could not find a competitor with this DOM virtualization capability.

The following are primary data display and editing grid scenarios that are critical in the overall user experience, and for which we have done the performance tests.

• Flat data binding
• Sorting (string, numeric)
• Filtering (string, numeric)

Unless otherwise specified, we show test results using a data set that includes 10 columns (all main data types) and 1,000 JSON records. Furthermore, our grid configurations have been based upon the following:

• Fixed height of the grid. If there is a property similar to our "autoAdjustHeight" property, then it has been set to false. In most business applications you will have a fixed size where you can place your grid.
• Each column has been given a fixed width
• Virtualization that has been set to false
• Alternate row styling (common to most of business applications)
• Horizontal and vertical scrollbars are visible
• Our jQuery grid's property, "applySortedColumnCss", has been set to false.

Our performance whitepaper reviews speed in terms of milliseconds, as well as memory and CPU usage. Speed and memory have been detailed on a per browser basis. Finally, memory consumption numbers have been calculated manually after monitoring the Task Manager process viewer of the OS. During all of our performance testing, we found CPU usage was almost identical between our jQuery grid control and its competitors (although our CPU usage is slightly better).

We measured the time it takes to bind to 1,000 JSON records with 10 columns on the Infragistics jQuery grid control and competitors, taking measurements at each of the following stages:

• Initial Load
  • Begin - From the moment exactly before the corresponding grid control starts loading
  • End - Links to the corresponding event exactly after the grid is rendered or the layout is updated
• Sorting
  • Begin - From the moment exactly before a sorting operation
  • End - Exactly after the sorting operation is finished (without rendering)
• Filtering
  • Begin - From the moment exactly before a filtering operation
  • End - Exactly after the filtering operation is finished (without rendering)

jQuery Grid Performance - Internet Explorer® 8

Table 1. Operation durations in milliseconds under Internet Explorer 8.

jQuery Grid Performance - Internet Explorer 9

It should be noted that after we captured all of the Internet Explorer 8 results in our performance tests, we upgraded to Internet Explorer 9.

Table 2. Operation durations in milliseconds under Internet Explorer 9.

jQuery Grid Performance - Firefox® 4

Table 3. Operation durations in milliseconds under Firefox 4.

jQuery Grid Performance - Chrome® 11

Summary

We have shown how you can further drive value with the Infragistics jQuery grid control through time-savings and the perceived user experience that having the fastest jQuery grid available anywhere gives you. These advantages come from our solid architecture based on virtualized DOM elements, and the strictness of the best practices and performance testing methodology we follow every day. The Infragistics jQuery grid control not only makes your Web applications look better, but it outperforms anything available on the market today.  Undoubtedly, this will lead to higher end user satisfaction for your users, and dollar savings for the applications you deploy.

To get the rest of our performance results, download the jQuery Grid performance whitepaper now!!

Below are Excerpts from our WPF and Silverlight Charting Performance Whitepaper

Infragistics Silverlight Data Chart in our NetAdvantage® for Silverlight Data Visualization product and the Infragistics WPF Data Chart in our NetAdvantage for WPF Data Visualization product are the fastest XAML charting controls available, with lightning fast refresh of millions of data points within milliseconds. Our performance testing centered on the following areas we determined were criticial to the overall user experience for data display and editing:

• Data binding
• Zooming/Scrolling
• Adding, Editing and Removing data points
• Live data scenarios

We include here an excerpt of the results from our performance testing. You can download the full performance whitepaper at the end of this section. Unless otherwise specified, we are showing the results of tests executed using data sets generated using a sinusoidal function.  While we tested several data series, we found that only in a few of them (Area, Line and Scatter) could we compare our WPF and Silverlight Data Chart controls with equivalent features found in our competition.

Data Binding

To test the performance of basic data binding we created tests that measure the amount of time needed to bind the Silverlight Data Chart using different series types, and render up to the LayoutUpdated event. We believe this most accurately represents what an end user experiences when waiting for data to load.

Figure 1: Area Chart - Binding times for 1,000 and 1,000,000 data points (in milliseconds)

Figure 2: Line Chart - Binding times for 1,000 and 1,000,000 data points (in milliseconds)

Figure 3: Scatter Chart - Binding times for 1,000 and 1,000,000 data points (in milliseconds)

Zooming/Scrolling

Zooming is de facto a combination between vertical and horizontal scrolling. Because of that, and in order to keep this whitepaper brief, we will show numbers only for zooming. The statistics related to zooming performance can be used as a proxy for scrolling performance.

We used a Silverlight automation framework for zooming scenarios which sets a new scale for the chart by dragging and selecting with the mouse a rectangular region into which to zoom. We calculate the time duration and memory usage between the raising of the MouseLeftButtonUp and LayoutUpdated events of the chart control.

After these zooming/scrolling tests we realized because most of our competitiors performance samples are enabled only with horizontal scrolling, their samples are noticeably slower if both scrolling types are enabled.

Figure 4: Area Chart - Zooming times for 1,000 and 1,000,000 data points (in milliseconds)

Figure 5: Line Chart - Zooming times for 1,000 and 1,000,000 data points (in milliseconds)

Figure 6: Scatter Chart - Zooming times for 1,000 and 1,000,000 data points (in milliseconds)

Update data source chart scenarios

Performance during data source updates relates to many end user charting scenarios when the user needs to see a change in the data immediately, and it's critical for their decision making (for instance, live stock tick data).  In the following section, we discuss the performance for the scenario where data points are being added to the data source presented by the WPF and Silverlight Data Charts (additional scenarios are described in the whitepaper below).  For all of the "Update data source chart scenarios" we calculate the time duration and memory usage before updating the data source, and after the LayoutUpdated event of the chart.

Add data points to a chart

In this scenario we insert 10 data points, one-by-one, at the beginning of the data collection.

Figure 7: Area Chart - Time to Add 10 data points to 1,000 and 1,000,000 data points (in milliseconds)

Figure 8: Line Chart - Time to Add 10 data points to 1,000 and 1,000,000 data points (in milliseconds)

Figure 9: Scatter Chart - Time to Add 10 data points to 1,000 and 1,000,000 data points (in milliseconds)

Live data

When designing and implementing our XAML Data Charts, the primary goal was to provide a chart optimized for displaying live data with minimal performance and memory overhead. You can easily display a full screen graph, and it will still scroll smoothly while running and adding new values. There's a rendering engine behind our charts that ensures only the changed areas of the chart are repainted. Scrolling the chart means moving the already rendered image, and only painting in the newly vacated area to be displayed.

During all of our performance testing, we found that our XAML Data Charts, even with 1 million data points, support refresh rates of as little as several milliseconds (3-10 ms). With the competitors we tested, it was impossible to achieve these results.  Your applications will not only look better and be easier to use with our XAML Data Charts, but they will outperform anything available on the market today.

To get the rest of the results, download the Performance in the Infragistics WPF and Silverlight Charting whitepaper today!!

Below are Excerpts from our Silverlight Data Grid Performance Whitepaper

Infragistics Silverlight grid is the fastest Silverlight data grid control available, with the blazing speed you need for data-intensive line of business applications. Here is a brief excerpt of our performance testing.

Data Binding

To test the performance of basic data binding we created tests that measure the amount of time needed to bind the Silverlight grid to different ItemSources and render up to the LayoutUpdated event (or similar event). We believe this most accurately represents what an end user experiences when waiting for data to load.

Table 1: Binding to IList - 10 columns and 1,000,000 rows of data.

Table 2: Binding to ObservableCollection - 10 columns and 1,000,000 rows of data.

Vertical Scrolling

Our Silverlight grid offers two options when it comes to scrolling with the scrollbar thumb – Deferred or Real Time (Immediate). When you have hundreds of thousands of rows, deferred scrolling lets your users preview the record's value as they scroll (for example, in a tool tip) without having to populate all of the cells until the user has reached the point in the data grid where they want to go.

We created tests to measure the performance of both options.

For scrolling scenarios we use a Silverlight automation framework that drags & drops the thumb from the up to down scroller buttons, and calculate the time elapsed.

Deferred Scrolling

We could only test one competing grid with deferred scrolling, as it was the only one that offered this feature.

Table 3: Deferred scrolling with 91 columns and 600 rows of data.

Real-time Scrolling

As you will see in the performance results in table 4, real time (or immediate) scrolling is a big problem in Silverlight. Most vendor samples you see will load limited amounts of data because the scrolling performance of the control is very poor.

Table 4: Real-time scrolling with 91 columns and 600 rows of data.

*It seems that "Competitor II" has issue with scrolling because thumb cannot be moved to the end.

To get the rest of the results, download the Performance in the Infragistics Silverlight Grid whitepaper today!!

Below are Excerpts from our ASP.NET AJAX Grid Performance Whitepaper

Likewise, we performed performance testing and load testing on our ASP.NET AJAX data grid, WebDataGrid. Built on the Aikido Framework™ and taking advantage of lightweight ASP.NET AJAX messaging between the client and server, it excels past the competition. Here are some of our test results.

Single-user Browser Operations

These scenarios include the full cycle – browser rendering (using Internet Explorer® 8) and server response time. These tests more closely represent the customer experience when using the tested data grids.

Table 1: Time (duration in ms) - 10 columns and 300,000 rows of data.

So how do we achieve such amazing performance in our WebDataGrid?

The simple answer: it’s the rock solid architecture of the Aikido Framework on which WebDataGrid is based. Additionally, our payload size is smaller than our competitors.

What is "payload size?"

The intuitive definition: the amount of data exchanged between server (IIS) and client (browser).

Why a smaller payload size is better for performance

Exchanges of smaller amounts of data will be processed and rendered faster by the browser. Also if you have a constrained connection between server and client, this will be a huge benefit for you—because less data is transported on the wire.

Payload Size

Using Fiddler 2 we monitor the data exchanged between server and client. In the table below, we show a summary (sent + received) per operation.

Table 2: Payload Size (in bytes) – 10 columns and 300,000 rows of data.

Load Testing

When we saw how big our advantage is with a single-user, we decided to see what happens when we load our own and competitors' grids. We repeated the following steps for WebDataGrid and its competitors:

• We used the same environment and pages for load testing as mentioned above. We used a commercial Web loading tool on the client PC to simulate the load, but you can repeat this load testing with some of the available free Web loading tools.
• Scenario:
  • Initial request
  • Numeric filtering ("Less than")
  • Clear Numeric filtering
  • Paging ("Next")
  • Paging ("Previous")
  • Numeric sorting
• Run-Time Settings: We simulated "think time" between all operations, and fixed it to 2 seconds.
• Ramp-Up: Start 2 users every 15 seconds. We used 50 users.
• After the ramp up has been completed, the load tool continues to run the scenario for 1 hour.

Notes: All load tests were repeated several times to remove any chance that something can be wrong with the environment. Server and client PC were restarted after each test run. "Competitor II" cannot handle 50 users on this environment. IIS crashes each time with an out of memory error.

Table 3: Load Testing 50 Users for 1 Hour.

* - Amount of throughput (in bytes) on the Web server during the load test. Throughput represents the amount of data that the users received from the server at any given second.
** - The number of hits made on the Web server by users during each second of the load test.

As you can see on the first row, our Average Throughput (bytes/second) is 51% better than "Competitor I." This comes directly from our excellent payload size.

On the second row you see that using our WebDataGrid, users have around 11% better productivity per unit time.

So from that load test we can conclude that users will have 11% increases in productivity if they use WebDataGrid.

Finally, you should not forget that these results are achieved in environments where both PCs are on one network switch. In real life, the client and server may be separated by great distances and the network bandwidth will be limited, this percentage will increase because of the amazing payload size of WebDataGrid. These benefits could result in tens of thousands of dollars a week, and potentially millions of dollars per year in savings.

To get the complete results, download the Performance in the Infragistics ASP.NET AJAX Data Grid whitepaper today!!