Telerik's VirtualQueryableCollectionView weakness
A few years ago, while developing at WPF, he discovered Telerik components.
In general, the quality and the proposed functionality suited me, so I actively planted the employer at the employer on these components.
And there was one “silver bullet” that I always used when it was necessary to display large collections from the server on the client. It was a bunch of RadGridView and VirtualQueryableCollectionView as its ItemsSource. The algorithm there is quite simple. The user scrolls the grid, the grid climbs behind the elements, VirtualQueryableCollectionView fires events that it needs elements, and in the background I load the necessary pages from the server. Everything was good and this technique worked for many years.
But the cryptocurrency exchange project has recently been charged. Among the main evaluation criteria by the exchange user is the exchange rate and liquidity. In order to meet users' expectations, a bot was loaded that generated orders by API. Because cryptocurrency exchange rate volatility is high, orders often had to be canceled and new ones placed.
And once, the exchange back-office software began to fall with OutOfMemoryException. The profiler showed the following.
Thousands of new System.Object [] objects. At the same time, nothing happened in my code, there were no new requests to the server, there was nothing that I could suspect of such a swift memory devour.
Enlightenment came when I explained to my colleague the symptoms. The meaning is as follows. When a page is loaded into the VirtualQueryableCollectionView collection, I tell it the total number of list items on the server. And VirtualQueryableCollectionView inside holds a list equal in the number of elements, but filled with dummies. I think that just System.Object []. And so, when the number of elements on the server went to tens of millions (thanks to the bot), this list could not stand it. Yes, if you transfer the process to x64, then it does not give up so quickly, but it is also impossible to work, because resizing this list takes almost a minute.
Here is such a fairy tale about list virtualization and a silver bullet.
PS I understand that there is no need for the user on the interface to view collections of such a volume. The meaning of the text is to share experience with colleagues and, possibly, save someone time in the future.
In general, the quality and the proposed functionality suited me, so I actively planted the employer at the employer on these components.
And there was one “silver bullet” that I always used when it was necessary to display large collections from the server on the client. It was a bunch of RadGridView and VirtualQueryableCollectionView as its ItemsSource. The algorithm there is quite simple. The user scrolls the grid, the grid climbs behind the elements, VirtualQueryableCollectionView fires events that it needs elements, and in the background I load the necessary pages from the server. Everything was good and this technique worked for many years.
But the cryptocurrency exchange project has recently been charged. Among the main evaluation criteria by the exchange user is the exchange rate and liquidity. In order to meet users' expectations, a bot was loaded that generated orders by API. Because cryptocurrency exchange rate volatility is high, orders often had to be canceled and new ones placed.
And once, the exchange back-office software began to fall with OutOfMemoryException. The profiler showed the following.
Thousands of new System.Object [] objects. At the same time, nothing happened in my code, there were no new requests to the server, there was nothing that I could suspect of such a swift memory devour.
Enlightenment came when I explained to my colleague the symptoms. The meaning is as follows. When a page is loaded into the VirtualQueryableCollectionView collection, I tell it the total number of list items on the server. And VirtualQueryableCollectionView inside holds a list equal in the number of elements, but filled with dummies. I think that just System.Object []. And so, when the number of elements on the server went to tens of millions (thanks to the bot), this list could not stand it. Yes, if you transfer the process to x64, then it does not give up so quickly, but it is also impossible to work, because resizing this list takes almost a minute.
Here is such a fairy tale about list virtualization and a silver bullet.
PS I understand that there is no need for the user on the interface to view collections of such a volume. The meaning of the text is to share experience with colleagues and, possibly, save someone time in the future.
