Community
Participate
Working Groups
By convention opening an editor does a refreshFromLocal. This can trigger an autobuild as a side effect. I had a workspace that was not built and and autobuild got triggered when opening the first editor. Since there is no progress the workbench was not responsive during around 10 minutes.
*** Bug 6925 has been marked as a duplicate of this bug. ***
This is in FileDocumentProvider.createElementInfo. Is there any way around this?
Removing the "refreshFromLocal" call from the code editor opening sequence raises another major usability concern. (Out of sync notification when opening an editor.) Would it be possible for the Workbench to switch autobuild off when restoring previous state? JDT, e.g., disables autobuild for serveral of its compound actions to make it run only once rather than multiple times.
Moving to Platform UI for comment.
*** Bug 2505 has been marked as a duplicate of this bug. ***
- The autobuild will happen when the first editor is opened which may not be at startup. - There are some places in the workbench that we do not do a refreshFromLocal for free, like in the import and export. - If we turn autobuild off/on in the startup. Would it have to verify if the workspace is built when switching it on? Would it make that startup slower? Whenever a editor is opened, could we check if it is out-of-sync and open a dialog asking the user if we should refresh and then open a progress bar? Moving to Text for comment.
I added (experimental - for now -) code to AbstarctTextEditor that wraps the the init method of the editor part into a IRunnableWithContext and runs it in the context of the ApplicationWindow. This way at least progress is shown on auto build. The user knows what happens. Asking the user whether they want to refresh is not a valid alternative as if the user turns it down we'll immediately end up with CoreExceptions. I.e. the editor would not be opened. This does not solve the problem when restoring the editor in start up. If the editor is the front most editor and its input changed externally, the refreshFromLocal call triggers an auto build without any progress. This issue is still to be solved. I don't see how the editor itself could solve this without workbench involvement. I think any necessary autobuild should only happen after the workbench UI has been restored, so that the user sees the progress information. Moving to Platform UI.
Core currently does the autobuild when you refresh. The Workbench could turn off auto-build when restoring workbench state, then restore it after the UI has been restored, and provide a progress monitor. DJ, do you see any risk in doing this?
We don't encourage people to turn off auto-build for their own purposes and then setting it back on. Would calling IResource.isSynchronized(depth) and only call #refreshLocal when the resource is out of sync suit your needs?
Checkin isSynchronized first should not be any different than calling refresh directly. In the external modification case, you still need to do the refresh which will still trigger an autobuild. Also, I would imagine that refreshLocal should do this internally anyway, and not trigger a build if the file is already in sync. If we go ahead and turn off autobuild during workbench restore, what ill effects can happen?
From a technical point of view I don't see a problem with turning off autobuild during startup, and then turning it back on once you've got enough UI to display a progress bar. Turning autobuild back on will *not* automatically trigger a build, so the next operation to run will get the build. I would recommend turning on autobuild from within an IWorkspaceRunnable so that the build is forced right away.
We will do this for M5. To clarify: IWorkspace.run always triggers an autobuild if on, even if the body of the runnable does nothing?
Good thing I double-checked. It should cause a build, but it currently doesn't. Opened bug 28384 for this, targetting M5.
So, we are going to pay the price of one build on startup even when nothing was changed externally.
Eduardo makes a good point -- this change would cause a slightly higher build overhead. To quickly explain, our current optimization is that if autobuild is on, and the current workspace tree is unchanged, then we skip the build. This is incorrect if autobuild has just been turned on. In this case, we require a more complex check to see if anything has changed since the last incremental build. Since each builder may have been invoked manually during the interval when autobuild was turned off, this check has to be done for each individual builder on every project. This isn't a huge cost, but it would incur a hit over the current startup cost. To give a feel for this cost, this is the same overhead you get when a single file is modified when autobuild is turned on.
Knut, can you grease this in for RC2?
With my test workspace (org.eclipse.ui plugins loaded as source and prereqs loaded as binaries), delaying the auto-build and running it in a IWorkspaceRunnable (WorkspaceModifyOperation actually) costs about 5% over the time of the usual workbench restore. The average workbench restore with my test workspace is 13100ms without deferring the build and 13800ms with. These numbers are from a scenario using ProgressMonitorDialog for progress. The dialog popping up and doing nothing (in the normal use case without external changes) is annoying. I remember seeing somewhere how to tell it to not show if the operation is short running. I just can't remember where I saw that. I'll also try using the workbench window for progress. However, a dialog may be better since the build is part of workbench startup. I'll attach code, soon for Eduardo or Nick to review and release.
Created attachment 3892 [details] Workbench.java Workbench.java based on version 1.59 (current HEAD state)
Created attachment 3893 [details] messages.properties messages.properties based on version 1.96 Two new strings: Workbench.autoBuild = Building... Workbench.problemAutoBuild = Problem occurred while building workspace.
I realized that it's the status line progress indicator that is delayed. The attached code uses the active workbench window and falls back to using a progress dialog if there is no active workbench window. Using the status line instead of the progress dialog cuts the performance penalty of the fix by about 1% to under 4%.
Nick pointed out that the attached code does not take the refresh on startup feature into account. This would result in two bulds when the refresh results in resource deltas. We should move the refreshFromLocal followed by enableAutoBuild below the try/finally block. I'm not sure why we even have the try/finally block. All the methods inside the try block handle exceptions already. } finally { UIStats.end(UIStats.RESTORE_WORKBENCH, "Workbench"); //$NON-NLS-1$ } refreshFromLocal(commandLineArgs); enableAutoBuild(); // Listen for auto build property change events getPreferenceStore().addPropertyChangeListener(propertyChangeListener); This could be more refined since the refresh opens a progress dialog and the enableAutoBuild uses the status line.
Released attached changes with modifications shown above. Fixed in >20030306
