The replayer of CodingTracker is too slow

[reprogrammer]

I loaded the change sequence at cs-111/a59ed788-a72b-435a-b673-8b25e13e7e99/1.0.0.201105300951/codingtracker/codechanges.txt and left a break point at timestamp 1313081027570. Then, I replayed the sequence in "Fast" mode. It took about half an hour until CodingTracker failed by throwing an exception. I don't know how long it will take CodingTracker to reach my break point.

Even half an hour to reach a break point is too long. This long delay makes it impractical to replay CodingTracker change sequences.

• When I run the replayer in "Fast" mode, does CodingTracker still introduce some delay between replaying the operations, or the delay is caused by showing the changes in Eclipse editors?
• If the CodingTracker replayer is slow because every operation updates the Eclipse editors, is it possible to replay the CodingTracker changes behind the scenes without showing the Eclipse editors?
• Is it possible to replay the change sequence from the middle rather than the beginning of the sequence? I think CodingTracker snapshots the files every week and in some other rare cases. Let's assume that CodingTracker has recorded changes for two files f1 and f2, and the user is interested in replaying the events close to time t. Let t1 and t2 be the greatest timestamps less than t at which CodingTracker has taken snapshots of f1 and f2, respectively. Is it possible to start replaying the change sequence from timestamp min(t1, t2) instead of 0?

[Wanderer777]

@reprogrammer:

• In general, in the "Fast" mode, CodingTracker does not make any additional delays between the replayed operations. The only exception is saving an editor or a conflict editor (where there is a small 100 ms delay, which should be replaced with listening to IProgressMonitor#done()) and performing a refactoring delay of 2 seconds (and I do not know yet how to avoid this one). Considering that refactorings are performed (exactly performed, rather than undone or redone) not that often, this delay should not make a big different, though it would be really nice to find a way to avoid it. Besides, only refactorings that were recorded in older CodingSpectator versions are replayed. Since the May's release, CodingTracker records and replays low level changes produced by refactorings, and thus, there is no any delay involved. This makes fixing the refactoring delay problem very low priority.
• CodingTracker replays operations in Eclipse editors and this indeed takes some time. But this is the natural way of replaying operations, so we would not be able to avoid updating editors. And I am not sure if an active editor can be hidden in Eclipse. Possibly it could be minimized to show almost nothing, but it will still be shown, and hence, rendered. I think that even greater source of delay comes from displaying the replayed operations both in the sequence (could be avoided by filtering all user operations out) and in the bottom status bar (which currently can not be avoided). Hiding both the sequence and the status bar during the replay should boost the replaying speed considerably.
• In the last bullet you are describing something that we called "jump to" action in our discussions with Danny a long time ago, i.e. trying to start a replay at the closest possible position to the desired point without replaying all the preceding operations. But we reconsidered doing it at that time since the captured sequences were not big and there was no real need for such an option. I think that it is possible to implement this option, but the gain in replaying speed will be highly dependent on the underlying sequence and the operation that you want to jump to. Note that one of the postprocessing steps of CodingTracker will remove redundant file snapshots, thus limiting the use of this feature (but this should not affect CodingSpectator analysis, which you can do on sequences before this postprocessing step). Also, in my implementation of this feature, I am going to relax the conditions in several ways. For example, in your scenario, it would not be needed to consider a snapshot of file f1, if it is not edited after time t. Also, it would not be necessary to look for a snapshot of file f1, if file is edited after time t, but the first its edit happens after a snapshot of this file that happened after time t. In other words, this is very similar to live variable analysis, only here there are files rather than variables, where taking a snapshot of a file is assigning a variable, and editing a file is reading a variable, while the control flow is linear.

[reprogrammer]

@Wanderer777: What concrete actions are you going to take to increase the speed of replays? Are you going to implement the "jump to" action?

[Wanderer777]

@reprogrammer: Yes, I am going to implement the "jump to" action, but first I will stop showing additional information during the fast replay (i.e. moving the current user operation in the sequences and displaying its details).

[Wanderer777]

The previous commit adds the "jump to" action to the CodingTracker's replayer. To properly replay the operation sequence from the "jumped to" operation, make sure that the workspace is clean (e.g. click "Reset"). Also, do not jump inside operations that change the content of a conflict editor. Considering that such operations are very rare and you are interested in jumping to refactorings, this should not be a problem. Please let me know how it works out for you.

[Wanderer777]

In the above commit I fixed the way in which the "jump to" action works. It needs to consider that in between the operation to which a user wants to jump and the actual operation to which the jump is going to happen (which is established as the earliest of the closest snapshots of the files edited after the given "jump to" operation) there could be other file editing operations, which require to establish their corresponding closest snapshot operations and so on. Therefore, CodingTracker establishes the right operation to safely jump to iteratively, i.e. until there are no editing operations without preceding file snapshot operations after this "jump to" operation. As a result, although correct, it could happen that the closest point CodingTracker can safely jump to is quite far from the actual operation a user is interested in. So, as I wrote above, the usefulness of this new feature will be highly dependent on a particular operation sequence and the operation to which a user wants to jump to.

[Wanderer777]

Speaking about a way not to show Eclipse editors, I found that the easiest approach would be to minimize the window of the Eclipse instance that performs the replay. As a result, I measured an improvement in replay time of around 25% - 30%, which is significant. So, at the moment, the fastest possible replay looks like this:

1. Jump as close as possible to the desired operation or start from the beginning if interested in replaying the whole sequence.
2. Start replaying in the fast mode.
3. Minimize Eclipse window.

To facilitate this approach, I will add a message box that notifies the user that the replay is over or reached a breakpoint, also displaying the replay time. But, the message box sometimes is not immediately visible if other windows are open, so periodically checking the status of the replay is still needed.