Go To Type Performance - mini UI Spec.
Author: Ondrej Langr
$Id: index.html,v 1.4 2008/01/16 17:28:43 ondrej Exp $ (see full CVS history)
Table of Contents
When a developer is working on a large codebase, the initial scanning (after IDE startup) can take rather long time. However, the "Go To Type" dialog, often invoked as a first task after the IDE startup, is paused until the classpath scanning is finished. This gives a subjective impression of poor IDE performance after the startup.
As a performance enhancement, the data presented in the "Go To Type" will be in 6.1 present immediately, but it will be based on the classpath scan from previous IDE session. In case there were files added to (or removed from) the project sourcebase while the IDE was not running, the data presented in the Go To Type dialog short after startup may be obsolete and not contain newly added files (or still contain removed files).
However, this together with a new added asynchronous project loading can cause a situation when the dialog is opened and all projects are not yet loaded. In such a case, user would get only get types from projects opened until the moment when the dialog was invoked. And naturally, the changes done by the versioning update (described in previous paragraph) would not be reflected
Three bad situations (or their combination) could happen with the new approach when using the "Go To Type" dialog short after IDE startup if no precautions were taken:
(1) User could get a list of types from only a subset of projects (those loaded until the moment when the dialog was invoked).
(2) While the classpath scan is running, an attempt to find a class, added while the IDE was not running, is made. In this case, the search returns the list of types matching the searched string, but without the desired class, or <No Types Found> message (which is misleading since the class is physically present in the project source folder).
(3) While the classpath scan is running, the developer types the name of a class which has been removed by the versioning update. In this case, the class is present in the list despite that it is not physically in the sourcebase anymore.
(1) The "Go To Type" dialog should show the data it has as soon as it is "almost sure" that what user is looking for is present. Unless we have some research data or measurements, we consider that this is when all projects have been loaded, because at this moment, only files changed through versioning can differ from what the dialog is displaying. Classpath scan can still be in progress so the data may not be completely up-to-date (as a result of points 2 and 3), but this can be considered a rare case and this UI specification describes how to deal with this situation below.
(2) A warning should be added in case the classpath scan was running at the time the dialog was invoked to indicate the risk of the list being out of date. In most cases, the developer probably finds what s/he is looking for (the type looked for has been in the codebase for longer time or has already been scanned). In this case, since the "Go To Type" dialog is well known to the user, and the task is typically very fast, they should not even notice the warining message in the bottom.
Naturally, the warning should only be present when a classpath scan was running in the background when the dialog was invoked. In all other situations, the data in the dialog can be expected to be up to date and there is no need for the warning.
(3) Hopefully, this part can be solved by checking the existence of file container of each type in the list, so no UI indication is needed.