I have a class (in C++), call it Data
, that has thousands of instances (objects) when the code is run. I have a widget (in Qt), call it DataWidget
that displays attributes of the objects. To rapidly build the widget I simply wrote the object attributes to a file and had the widget parse the file for the attributes - this approach works, but isn't scalable or pretty.
To be more clear my requirements are:
1 - DataWidget
should be able to display multiple, different, Data
object's attributes at a time
2 - DataWidget
should be able to display thousands of Data
objects per second
3 - DataWidget
should be run along side the code that generates new Data
objects
4 - each Data
object needs to be permanently saved to file/database
Currently, the GUI is created and the DataWidget
is created then the experiment runs and generates thousands of Data
objects (periodically writing some of them to file). After the experiment runs the DataWidget
displays the last Data
object written to file (they are written to XML files).
With my current file approach I can satisfy (1) by grabbing more than one file after the experiment runs. Since the experiment isn't tied to DataWidget
, there is no concurrency, so I can't do (3) until I add a signal that informs the DataWidget
that a new file exists.
I haven't moved forward with this approach for 2 reasons:
Firstly, even though the files aren't immediately written to disk, I can't imagine that this method is scalable unless I implement a caching system - but, this seems like I'm reinvent the wheel? Secondly, Data
is a wrapper for a graph data-structure and I'm using Graphml (via Boost Graph Library i.e. *write_graphml()*) to write the structure to XML files, and to read the structure back in with Boost's *read_graphml()* requires me to read the file back into a Data
object ... which means the experiment portion of the program encodes the object into XML, writes the XML to a file (but hopefully in memory and not to disk), then the DataWidget
reads the XML from a file and decodes it into an object!
It seems to me like I should be using a database which would handle all the caching etc. Moreover, it seems like I should be able to skip the file/database step and pass the Data
to the DataWidget
in the program (perhaps pass it a reference to a list of Data
). Yet, I also want to save the Data
to file to the file/database step isn't entirely pointless - I'm just using it in the wrong way at the wrong time.
What is the better approach given my requirements?
Are there any general resources and/or guidelines for handling and displaying data like this?
-
It seems to me like I should be using a database which would handle all the caching etc. Moreover, it seems like I should be able to skip the file/database step and pass the Data to the DataWidget in the program (perhaps pass it a reference to a list of Data). Yet, I also want to save the Data to file to the file/database step isn't entirely pointless - I'm just using it in the wrong way at the wrong time.
If you need to display that much rapidly changing data, having an intermediate file or database will slow it down and likely become the bottleneck. I think the Widget should read the newly generated data directly from memory. This doesn't prevent you from storing the data in a file or database though, it can be done in a separate thread/process.
bias : How do I couple the classes so that the Widget class can access the Data properties? Do I inherit the Widget from the Data? -
If all of the data items will fit in memory, I'd say put them in a vector/list, and pass a reference to that to the DataWidget. When it's time to save them, pass a reference to your serializing method. Then your experiment just populates the data structure for the other processes to use.
-
I see you're using Qt. This is good because Qt 4.0 and later includes a powerful model/view framework. And I think this is what you want.
Basically, have your
Data
class inherit and implement QAbstractItemModel, or a different Qt Model class, depending on the kind of model you want. Then set your view widget (most likely a QListView) to useData
for its model.There are lots of examples at their site and this solution scales nicely with large data sets.
Added: This model test code from labs.trolltech.com comes in real handy:
http://labs.trolltech.com/page/Projects/Itemview/Modeltest
bias : Perfect, this also answers my concern of how do I uncouple the Data and DataWidget classes!Mark Beckwith : Great, I added a link to the modeltest code that is really useful.
0 comments:
Post a Comment