O
Oscar kind
exquisitus said:I have a heirarchical ADT whose innermost structure is a set of records.
Each record (C struct) has several fields and represents data
received from a real time feed. In C++, I am using the BOOST library to
allocate a memory pool from which I can request memory slices as and
when I need it. I can write the data directly from my feed to memory,
with (almost) no latency.
If the feed delivers the data exactly as stored, this is indeed ideal.
Java however, does not support structures like C does.
If there are slight differences however, you may want to evaluate a solution
like this:
- The feed handler receives a message, and determines it's type (if there
is more than one).
- Bases on the type, it creates a record, and gives the message to the
contructor.
- This constuctor then fills the "structure"
This is a data centric solution (and not nescessarily the best), and thus
favors objects. This as opposed to a process centric solution, that by its
nature favors stuctures. You'll realise that each is more appropriate in
different cases.
In Java (I am a newbie - so hopefully you can
correct me), I find that I have to wrap up the ADT which is so naturally
a struct, into a heavy, clumsy object. Everytime I receive data, I have
to create a new data object (an encapsulation of the C struct) and then
add it to my array.
Not entirely: the struct becomes the object. The easiest way to do that is
to add the method that fills if to the structure, and you have an object.
The mconstructure I mentioned above is an example of that.
The perfomance hit on creating so many objects is
(unsuprisingly) abysmal when compared to the C++ code. In practise, I
can expect to receive about 50 such records per second, and can receive
as much as 50,000 records in total. The thought of spawning 50 new
object a second - not to mention having 50,000 bloated objects hanging
around in memory is not a pleasing prospect.
Objects don't have to be that bloated: the performance hit in terms of
storage only becomes big if the amount of fields in the structure is
small (maybe 5 or less, but I have no real knowledge of that).
So I will say once again (and this is not to encite the wrath of the
more experienced Java programmers). Please tell me it isn't so (I will
gladly accept a better solution if there is one - I have no ego as far
as this is concerned). There must be another way - a better way of
dumping these records into memory without having to create a new object
every time the data is received.
Alas, there is o other way: Java only knows of one type of structure, and
that is an Object (or subclasses).
Also, Java has no pointers, in the sense that it allows neither pointer
arithmetic, nor referencing functions (or methods, as Java insists on
calling them). So for a callback, you cannot use anything other than
objects.
Note that this isn't as bad as it may seem: you only create one object per
callback. This is regardless of how many times the callback is used: the
callback method is called on the same object again and again.