Performance
We actually had an interesting time testing the performance of CLINQ. Without being bound to any GUI, we are able to pump over 1,000,000 changes per second into a source collection (with an upper cap on collection size to avoid running out of resources) with a large CPU load, and at 100,000 changes per second the load looked to be sustainable indefinitely.
The real tricky part came when trying to bind CLINQ to a WPF GUI. Thanks to Pavan Podila from the WPF Way (pavanpodila .spaces.live.com), we were able to track down a potentially fatal problem with data binding. In our ListBox, the height wasn't explicitly set, which prevented the item container style from being a VirtualizingStackPanel. Added to that was the template selector for picking the alternating grid style that could get invoked every tick for each of the hundreds of thousands of bound rows. Lesson learned: Make sure that your bound control remains virtualized and be very careful with item styles and item container styles when working with large data sets. Taking these precautions, we were able to get nearly the same throughput into CLINQ when databound as we were when using no GUI at all.
Using code like Listing Two, I've constructed a sample Order Book demo that lets you open windows into arbitrary symbols with simulated market data coming in at fixed intervals; see Figure 2.
This window contains two listboxes. Each listbox is bound to a subset of market data. The BUY listbox is bound to the bid ticks for AAPL and the SELL listbox is bound to the ask ticks for AAPL. As new market data comes in to the central market data store (could be from network messages or, in my case, from a background thread on a timer), each set of query results is updated dynamically. If new market data for symbols other than AAPL comes in, the query results are not affected. If a new tick comes in for AAPL, it is placed in the appropriate listbox based on the side of the tick. All of that work, decision making, and data propagation is done automatically by the CLINQ language extension.
Fortunately, language extensions and CLINQ specifically can be used for pleasure as well as business. The following query is one that might be used in a strategy game to detect all nearby ships within your particular radar range:
_visibleObjects =
from radarObject in _rawRadar
where radarObject
.Distance2DFrom(_myLocation)
<= RADAR_RADIUS
select radarObject;
Such a game could receive a continuous stream of network messages from connected peer applications and store those messages in a ContinuousCollection (such as _rawRadar). The collection _visibleObjects would automatically update everytime an object in the _rawRadar list changed position or objects were added or removed.
Figure 3 shows the results of that query bound to a custom-style listbox to create a WPF-based radar view of nearby enemies.
Conclusion
Continuous LINQ is just one expansion made possible through language extensions and LINQ on the .NET Framework 3.5. By embracing these features of the upcoming version of .NET, you can be ready to not only provide the most advanced features in your applications, but you can be assured that if there are domain-specific query features that you want in your application, you can create them yourself quickly and easily.
You can download the samples used in this article, as well as the CLINQ code itself, from my blog at dotnetaddict .dotnetdevelopersjournal.com.
