Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Ideas about pin and new view features


On Mon, Jan 16, 2017 at 12:07 PM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@xxxxxxxxxxxx> wrote:

It's a good start. Could those identifier (trace+ number) be replicated to in-sync view tab name ? (Views currently in sync with that even table [trace])

Yes, they are used as the tab name for the trace editor (event table) and for the updated 'pinned' view tab name.

I'm not sure if we should add the active trace name to the unpinned views, or even ultimately keep it for pinned views. When appended to the view name and [Pinned] indication, it makes for a really long tab name, it takes a lot of space in the tab folder and can cause the view toolbar to be displayed in its own row.

There sure is a need to help the user understand which view corresponds to which trace though, but I'm not sure if there is a better way than this. Colors? Tool tips?

Yes exactly. And they have their own trace context (window range, time selection) in the trace manager
Could this be a problem performance wise ?

What could be an issue is the duplication of opened OS file system handles by each instance of the CTF Reader.

When it comes to supplementary files (e.g. state system history files), the second instance will reuse the same file if it exists. If it's in progress of being built, it still seems to work but I didn't investigate which already existing safeguard makes this OK ;)

If there's an analysis that keeps its result in memory, presumably it would have need copies of the result for each instance.

I can see a couple of ways to address this issue:

1) Change the concept of 'active trace' to 'active trace context' in the framework, then allow multiple contexts per trace instance. For example handling of trace selected signal would need to be replaced or augmented to consider the trace context as the selected object. The worry is that all existing framework or external code would need to be checked to make sure if handling of ITmfTrace instance by itself is still appropriate.

2) Somehow be able to create multiple trace instances that are backed by the same trace reader, checkpoint indexer, analysis results, etc. while still keeping the same characteristics (e.g. must be an instance of its specific trace class, not an instance of some internal Trace Compass wrapper class).

Both seem quite complex and risky, maybe it can wait to see if there is really a problem.

Hmm, I answered thinking about resource depletion, but you were asking about performance... I'm not sure how multiple trace instance could be worse performance wise (if there is enough memory), maybe shared caches (like in the state system) have less cached nodes per trace because there are multiple trace instances? But it's the same as today when opening completely different traces.


Back to the top