Skip to content

Changes

Summary

  1. tmf.ui: Cache size and bounds on resize or move (details)
  2. analysis: Fix resource leak in CompositeHostModel (details)
Commit a839e1659750c2e89976f7aa9ed431c315abbac4 by Matthew Khouzam
tmf.ui: Cache size and bounds on resize or move

It is impossible to resize while in a paint operation, so the getSize()
and getBounds() operation can be cached. In doing this, each link does
not call the getSize() and getBounds() functions twice per draw.

Accelerates from 15s/draw to 500ms/draw on "bar code" style images.

This is very evident on trace compass traces, especially while using
LogLevel#Finest

[Changed] Improve performance of timegraph with many links/markers

Change-Id: I7e228056ef28a988d4c8d7fb3803f16e1b1bfb6d
Signed-off-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/c/tracecompass/org.eclipse.tracecompass/+/201710
Tested-by: Trace Compass Bot <tracecompass-bot@eclipse.org>
Tested-by: Patrick Tasse <patrick.tasse@gmail.com>
Reviewed-by: Patrick Tasse <patrick.tasse@gmail.com>
The file was modified tmf/org.eclipse.tracecompass.tmf.ui/src/org/eclipse/tracecompass/tmf/ui/widgets/timegraph/widgets/TimeGraphControl.java (diff)
Commit fc4226b7cd0d79b00368915dc6210ade9e35336d by Patrick Tasse
analysis: Fix resource leak in CompositeHostModel

The original design had some flaws:

- The CompositeHostModel is instantiated in many cases, for example when
a kernel analysis module is created. But it is only disposed from
ModelManager when an InstrumentedCallStackAnalysis is disposed, which
only happens if a LTTng UST trace is opened in the experiment. Therefore
the CompositeHostModel leaks when opening a single LTTng kernel trace.

- When the InstrumentedCallStackAnalysis is disposed, all models are
disposed, regardless of whether the models are still in use by another
opened trace.

- The CompositeHostModel is disposed, deregistering itself from the
signal manager, before it has had time to handle the TmfTraceClosed
signal, which means this signal handler's cleanup tasks are not done.

The implemented fix implements these changes:

- Remove the responsibility from InstrumentedCallStackAnalysis to
dispose the models.

- Add the responsibility to CompositeHostModel itself, in the
TmfTraceClosed signal handler, to dispose all models, but only if there
are no remaining opened traces. This means the models remain in memory
when other traces are still opened, whether they are associated with
these traces or not.

Change-Id: I2fb8c836c5498266b757b115466be13d8e02b05d
Signed-off-by: Patrick Tasse <patrick.tasse@gmail.com>
Reviewed-on: https://git.eclipse.org/r/c/tracecompass/org.eclipse.tracecompass/+/202404
Tested-by: Trace Compass Bot <tracecompass-bot@eclipse.org>
Tested-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
(cherry picked from commit c92ebcc5cdb17b3f809ee6b49904b66b223cda6d)
Reviewed-on: https://git.eclipse.org/r/c/tracecompass/org.eclipse.tracecompass/+/201994
The file was modified analysis/org.eclipse.tracecompass.analysis.callstack.core/src/org/eclipse/tracecompass/internal/analysis/callstack/core/model/CompositeHostModel.java (diff)
The file was modified analysis/org.eclipse.tracecompass.analysis.callstack.core/src/org/eclipse/tracecompass/internal/analysis/callstack/core/instrumented/InstrumentedCallStackAnalysis.java (diff)