| Re: [tracecompass-dev] Change to experiment trace persistence |
Hi Patrick
It’s an interesting improvement. Minimizing the number of links in Eclipse, gives an performance improvement because the .project file doesn’t have to be rewritten for each link.
I’m ok with this change. Trace Compass 4.0 major release is a good time to do this type of changes.
Thanks
Bernd
From: tracecompass-dev-bounces@
eclipse.org [mailto:tracecompass-dev-bounces@xxxxxxxxxxx ] On Behalf Of Patrick Tasse
Sent: February-27-18 5:13 PM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Subject: [tracecompass-dev] Change to experiment trace persistence
Hi,
I'd like to give everyone a heads up about an upcoming change to Trace Compass:
tmf: Make experiment traces persisted as empty files
https://git.eclipse.org/r/118088 This has to do about how Trace Compass persists experiments in the tracing project so that the model can get recreated later from the workspace resources.
An experiment is persisted as a folder under <Project>/Experiments. The folder has the experiment name. Under this folder there is a subfolder structure that mimics the experiment trace's relative path to the Traces folder. At the leaves of this structure are the experiment traces. The reason that the folder structure is recreated under the experiment is to avoid name clashes of traces from different folders, while supporting the model convention that every trace element maps to a unique resource.
Before this change, the experiment traces were stored as linked resources (IFolder.createLink or IFile.createLink, depending on whether the trace itself is a file or a CTF folder). The location of the link was set to the location of the corresponding trace's resource in the Traces folder (if that trace was itself a linked resource, the location would be the target of the link).
MyProject/Experiments/myexp/
foo/bar/trace [1] MyProject/Traces/foo/bar/trace [2]
So trace [1] was a linked resource with the same location as the location of trace [2]. To correlate trace [1] with trace [2] we look for a trace that has the same element path relative to the Traces folder as the relative path of the experiment trace relative to its experiment, e.g. "foo/bar/trace".
With the proposed change, trace [1] becomes simply an empty file. We can use the same relative path strategy to find the corresponding trace in the Traces folder.
The reason for the change is to avoid having a great number of linked resource in the project, as each linked resource is persisted by the Eclipse platform as an element in the .project XML file. As the number of linked resources grows, adding or removing links gets progressively slower as each change requires reading/writing the full XML project description. When batch creating multiple experiments this can become a very slow operation.
So what does this mean for users?
The change is backward compatible, so experiments created before the change will be recreated correctly when the workspace is used with the new code.
However the change is not forward compatible. If an experiment is created with the new code, and the same workspace is then used to run an older version of the code, the experiments will appear empty as the empty files are not handled by the old code. If the user adds traces to the experiments while running the old code, linked resources will be created without problems and they will overshadow the empty files.
From the UI point of view, one minor change is that the link decorator on experiment traces in the Project Explorer will now only appear if the corresponding trace in the Traces folder is itself a linked trace.
This changed is planned to be merged in the master branch, to be released in Trace Compass 4.0.0.
Best regards,
Patrick
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass- dev