| Summary: | [cache] Inefficiency in CommandCache | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marc Khouzam <marc.khouzam> | ||||
| Component: | cdt-debug-dsf | Assignee: | Project Inbox <cdt-debug-dsf-inbox> | ||||
| Status: | CLOSED INVALID | QA Contact: | Pawel Piech <pawel.1.piech> | ||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | pawel.1.piech | ||||
| Version: | 6.0 | Flags: | marc.khouzam:
review?
(pawel.1.piech) |
||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks to the JUnit tests I realized this 'fix' was bad.
I wanted to optimize:
for ( CommandInfo unqueuedCommand : new ArrayList<CommandInfo>(fPendingQCommandsNotYetSent) ) {
if ( unqueuedCommand.equals( cachedCmd )) {
fPendingQCommandsNotYetSent.remove(unqueuedCommand);
fPendingQCommandsSent.add(unqueuedCommand);
break;
}
}
the problem turns out to be that 'cachedCmd' although considered equals() with 'unqueuedCommand', is not actually identical. 'cachedCmd' does not contain the list of requestMonitors that unqueuedCommand contains.
So, we actually need to fetch unqueuedCommand from the fPendingQCommandsNotYetSent map before inserting it in fPendingQCommandsSent
I've added a comment in the method to explain this.
|
Created attachment 166615 [details] Proposed improvement While looking at CommandCache, I noticed a potential minor inefficiency. Pawel, are you ok with this change?