Telerik's VirtualQueryableCollectionView weak spot
A few years ago, while developing on WPF, discovered the components from Telerik.
In general, the quality and the proposed functionality suited me, so I actively hooked the employer to the employer on these components.
And there was one “silver bullet” that I always used when I needed to display large collections from the server on the client. It was a bunch of RadGridView and a VirtualQueryableCollectionView as its ItemsSource. The algorithm there is quite simple. The user scrolls the grid, the grid climbs behind the elements, VirtualQueryableCollectionView shoots events that it needs elements, and I load the necessary pages from the server in the background. Everything was fine and this technique worked for many years.
But recently, a cryptocurrency exchange project was charged. Among the main criteria for evaluation by the user of the exchange is the course and liquidity. In order to meet user expectations, the bot was generated, which generated orders using the API. Since The course volatility of cryptocurrency is high, orders often had to be canceled and put up new ones.
')
And once the back office software of the exchange began to fall with OutOfMemoryException. 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 in such a rapid devouring of memory.
Enlightenment came when I explained my symptoms to a colleague. The meaning is as follows. When the page is loaded into the VirtualQueryableCollectionView collection, I inform it of the total number of list items on the server. And the VirtualQueryableCollectionView inside holds a list equal to the number of elements, but filled with dummies. I think just System.Object []. And so, when the number of items on the server went to tens of millions (thanks to the bot), this list could not stand it. Yes, if you translate 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 tale about list virtualization and silver bullet.
PS I understand that the user on the interface does not need to look through collections of such volume. The meaning of the text to share experiences with colleagues and, perhaps, save someone time in the future.
In general, the quality and the proposed functionality suited me, so I actively hooked the employer to the employer on these components.
And there was one “silver bullet” that I always used when I needed to display large collections from the server on the client. It was a bunch of RadGridView and a VirtualQueryableCollectionView as its ItemsSource. The algorithm there is quite simple. The user scrolls the grid, the grid climbs behind the elements, VirtualQueryableCollectionView shoots events that it needs elements, and I load the necessary pages from the server in the background. Everything was fine and this technique worked for many years.
But recently, a cryptocurrency exchange project was charged. Among the main criteria for evaluation by the user of the exchange is the course and liquidity. In order to meet user expectations, the bot was generated, which generated orders using the API. Since The course volatility of cryptocurrency is high, orders often had to be canceled and put up new ones.
')
And once the back office software of the exchange began to fall with OutOfMemoryException. 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 in such a rapid devouring of memory.
Enlightenment came when I explained my symptoms to a colleague. The meaning is as follows. When the page is loaded into the VirtualQueryableCollectionView collection, I inform it of the total number of list items on the server. And the VirtualQueryableCollectionView inside holds a list equal to the number of elements, but filled with dummies. I think just System.Object []. And so, when the number of items on the server went to tens of millions (thanks to the bot), this list could not stand it. Yes, if you translate 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 tale about list virtualization and silver bullet.
PS I understand that the user on the interface does not need to look through collections of such volume. The meaning of the text to share experiences with colleagues and, perhaps, save someone time in the future.
Source: https://habr.com/ru/post/263909/
All Articles