Re: [tracecompass-dev] Trace Compass state snapshot exchange format

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

Hello tracers,

I have a summary of my thoughts here, I can go in depth if need be.

To be honest, I find this very complex as a way to dump the full state
history and segments at a given time of a trace. Are there any other
places this can be used? I would go with a tree.json alone. Have the
types in also, we only support 10000 attributes / ss. So that means we
are saving 10k (more once Loic's patches are merged) values of worst
case 4 instead of "String", so we are saving 8 chars or 80 K of disk
space with this operation. In practice we are probably saving more like
80-800 bytes since a real average state system is 10-100 deep. What we
are also doing is creating an opportunity to lose a file and render the
state system illegible. I would suggest instead making a full tree.json
and if you find it too large, zip/bz2/gzip/xz it.

Also, will it save the segments in the segment store? this is a valid
issue as we have several (especially with XML) segment stores being used
at this moment. I think we don't want to lose the segments being
created. It may be out of scope though for this rfc.

Something I would NOT recommend that would save space too would be to
replace "value" with "v", as it is repeated very often.

Finally, the 'history.bin' is not really detailed. Is it:

<philippe>

* A state history and a state snapshot have an intersection
  (`types.json` and `tree.json`), which means common code to produce and
  consume both. They should be already produced when taking the snapshot
  in fact.

</philippe>?

Could you sell me on why these three files are more interesting that say
a json output of the analysis id, the state, and the layout, then it is
the responsibility of the analysis to be able to load its snapshot?

This is just my 2c though.

Cheers

Matthew