| RE: [linuxtools-dev] TmfEventContent data storage |
|
Hello, I had a look
at the patch you sent and I think it’s a big performance issue in these
changes that are made. The problem is
that the content now parses the fields in the constructor which means that the
map of fields is generated even for events that are only used to index the
trace. Also I think
that the map of field id’s to field values that is stored in each event
is a performance issue. Why do you not keep the access function with the
integral id? When used from a GUI side it would also be much faster getting the
field values by an integer than by a String. Because a GUI would normally get a
list of labels for the columns and then fill it with fields. It makes no sense
from my point of view having an accessor function by a field label which would
end up in a map-lookup. And finally - why
is data stored that often in the TMF class structure? The content holds a list
of field labels and a reference to the type. The type holds a list of field labels.
The content holds a map of field label to values. And finally the field itself
holds a copy of the field label. That means that each field label is stored on
4 different places within the same object. For the content I think it would be
much faster to store a type reference. The list of field names can then be
retrieved by asking the type. And the map should be replaced by a list of
fields (like it was before) that is lazy-parsed. This way indexing will
speed-up a lot. Regards, Franz From:
linuxtools-dev-bounces@xxxxxxxxxxx [mailto:linuxtools-dev-bounces@eclipse.org]
On Behalf Of Francois Chouinard I posted a first patch in https://bugs.eclipse.org/bugs/show_bug.cgi?id=287562. |