Comparison Features in MAT

[eclipsewebmaster]

| --- | --- | | Bugzilla Link | 298078 | | Status | ASSIGNED | | Importance | P3 enhancement | | Reported | Dec 17, 2009 09:30 EDT | | Modified | Oct 13, 2020 13:01 EDT | | Depends on | 305150, 305152, 305154, 347648, 394222, 541539, 561460 | | Blocks | 271908, 283778 | | Reporter | Krum Tsvetkov |

Description

The existing comparison possibilities inside MAT are very limited. We would like to provide much more flexibility (and hopefully value) to the users when it comes to comparing different tables / results inside MAT. After some discussions we have some ideas what to provide. These ideas I have tried to summarize below.

These give just a high level overview of what we think would be useful. More detailed technical discussion how to implement them should follow. I will also attach a pdf version of the text below for easier reading.

-------------------------------------------------------------------------------------------------------------------
Comparison Features in MAT

1. Comparison of two or more arbitrary tables

1.1 Requirement

It should be possible to compare in MAT two and more arbitrary result tables which have similar columns, for example two histograms, two retained sets, two results from the ?groub by value?, etc? These result tables can be from one and the same heap dump, or from two or more different heap dumps.
Having this functionality one can do things like:

• Compare the retained heap of the session for userA and userB (both within the same heap dump) and see why one is bigger than the other
• Analyze how the retained set of userA?s session is changing over time (comparing heap dumps from different tests)
• Compare several group_by_value results and find which Strings appear in one set and are missing in another one, how the number of occurrence changes, etc?
  It should be possible to (re)order the results in an arbitrary way.

1.2 Comparing

1.2.1 Selecting the results to be compared

The first important question that has to be solved is how to select the tables which should be compared.
Our current proposal is to use the ?Navigation History? view which contains all currently open results + all results which could be recreated.

The selected results should go into something like a ?compare container? where one can reorder them if needed.
We additionally thought about drag & drop into such a container, but as a beginning the navigation history seemed to be the better approach.

1.2.2 Finding the common ?key?

The next thing to decide is which column should be used as a key for the comparison. We didn?t come up with a good use case where the first column is NOT proper. Therefore for simplicity we would assume that always the first column is the key ? usually a class name, the string from ?group_by_value?, etc?
The first column of the result should be the union of all keys. It should be possible to distinguish (based on the other columns) if some keys were not present in some of the compared tables.

1.2.3 Comparing the columns

Columns with the same name should be compared. If one of the compared tables has a column which is not present in the rest of the tables, then it could be either ignored, or we could make it visible that such a column didn?t exist.
For each common column there should be N columns in the result, presenting the absolute values (or deltas) from each of the N compared tables, e.g.:

Class Name | Shallow #1 | Shallow #2 | Shallow #3 | Retained #1 | Retained #2 | Retained #3
ClassA | | | | | | |
ClassB | | | | | | | ...

1.3 Displaying the result

1.3.1 What to display - delta or absolute numbers

The first displayed value for every compared column should be the absolute value of the first compared table, e.g. the absolute ?shallow size #1?. The user should be able to select if he wants to see for the rest (?shallow size #2? and ?shallow size #3?) the delta to the previous, the delta to the first, or the absolute value. A button in the toolbar should be fine for this.

1.3.2 Selecting columns to be compared / displayed (e.g. Shallow Heap, Retained Heap, etc?)

Another important question to decide is which columns (besides the key) should be compared. One option is to open a wizard / dialog before the comparison is executed. This however adds always one step, even if all columns are desired.
Therefore our current suggestion is to compare and display initially all columns, and make it very easy to for the user to show / hide them. Having one button per column in the toolbar could be one solution. The user will just have to Press/ Release the corresponding button if the information in the compare result is too much.

1.4 Continue from the result (context menus)

Once the comparison result is displayed, the user should be able to interact with it, i.e. execute further queries on certain rows / cells of the result. Therefore the corresponding context menus have to be provided.

1.4.1 Execute queries with the objects behind a concrete table cell

It should be possible to open a context menu and say ?show the retained set of the objects of classA, from the first table that was compared?

1.4.2 Execute queries on a row ? next compare step

It should be possible to open a context menu on a certain row R of the comparison result and say ?execute query X on row R of each of the underlying tables, compare the results, and show me a table with the compared results?. For example if we have compared 3 histograms, each of them containing a row with String, I should be able to right click on String in the comparison result and execute ?group by value? on all of them. Then the tool should run behind the scenes group by value on each of the 3 rows and show me at the end a comparison for the 3 group by value results.

2. Reports / queries over several heap dumps

Once the functionality to compare arbitrary results is present, we should:

• Provide the possibility to execute an existing query on more than one heap dumps and compare the results, e.g. replace open the histogram in three dumps, select the results for compare and compare them, with something like ?run histogram on ?? and select the dumps.
• Provide the mechanism to have queries which take several snapshots as a parameter, e.g. @Argument ISnapshot[]. The UIs for selecting and ordering the heap dumps should be outside the queries.
• Provide the possibility to execute a report over several heap dumps via the scripts, without UI.

Having these we should be able to try out and implement some leak searching algorithms based on comparison of multiple heap dumps.
-------------------------------- end of proposal -----------------------------------------------------------------

Feedback is appreciated!