Community
Participate
Working Groups
Created attachment 280056 [details] Trace java.util.concurrent.Semaphore.tryAcquire called by EclipseStarter#updateSplash takes a ridiculous amount of time during a warm startup, see trace. We should try to make this faster or avoid doing it (that often).
Created attachment 280057 [details] Screenshot
I'm curious what effect making updateSplash faster would have on startup time. After all it is waiting for the start-level or refresh operation to complete and in the background is checking this semaphore to see if it is done and updateSplash should not continue until the operation blocking the Semaphore is done. At any rate it seems the Semaphore could be replaced by a simple AtomicBoolean.
Does it have to wait for every update or can it wait for all updates in one place?
(In reply to Lars Vogel from comment #3) > Does it have to wait for every update or can it wait for all updates in one > place? Actually thinking about this. The reason it looks like this tryAcquire is taking so long is because it has a timeout of 50 ms. The reason we wait for 50 ms is because that ends up being the refresh rate of the splashscreen. I now think there is nothing to do here, it is not taking up CPU time, just mosting waiting for the operation to complete and every 50 ms doing an update of the splashscreen.
New Gerrit change created: https://git.eclipse.org/r/150414
New Gerrit change created: https://git.eclipse.org/r/150413
In an RCP application I have an immediate component. ---- @Component(immediate = true) public class WFCTranslationDownloadService { public WFCTranslationDownloadService() { System.out.println("Download zip file"); } } ---- During startup the main thread blocks in #updateSplash in if (semaphore.tryAcquire(50, TimeUnit.MILLISECONDS)). Is this expected?
