OK, I got it. Looking at how intensive your data exchange is, I seriously doubt that the whole architecture is reasonable. But, as I don't know the ultimate purpose of all this activity, I cannot advise anything particular to improve it.
At the same time, the idea to infinitely populate an instance of a
, especially of relatively high rate won't work for you anyway, no matter how much effort would you pay to "optimize" it. Did you think that sooner or later, it may happen that all of your available RAM will be not enough to hold your UI?
So, there can be different approaches; and I cannot overview them by the reason I explained above. So, the first principle you should embrace is: the UI user never needs to see all messages at once
. Once you understand it, you will be able to design you UI in a reasonable way.
So, first of all, you should not update your
, even if you use one as data is received. Instead, you should have one small control which is update when each message comes. For example, if could show just three-four data elements, say, current number of messages, two points of time: for a very first and the last received messages; and, maybe also something like ID (name, description, you name it) of your most recently received message, only one.
First of all, as your first action on receiving messages, you should dump all received messages on disk
; you just have no other choice. The data should be represented as it is received and as the user decides to look at it
The user should be able to select what range of messages to look at. One (not so simple) approach would be using the same very
instance, but in virtual mode:
The user will have an impression of all the available data is available at once, but the range of messages should populate only the visible part of grid view as the user scrolls it
. This is a very usual solution for big volumes of data.