Community
Participate
Working Groups
Created attachment 276402 [details] profiler screenshot After bug 540487 was implemented I tried understanding the tracing being used there and decided to also run a profiler. Looks like there are some further things that are worth improving: * Class loading of RepoChangeScanner takes half a second on my fast laptop. We may want to put that into a job, too. * Initialization of the SSH stuff takes half a second. Can we put that into a job? I don't really have an understanding of what that does and whether we can do that later.
(In reply to Michael Keppler from comment #0) > * Class loading of RepoChangeScanner takes half a second on my fast laptop. > We may want to put that into a job, too. I *guess* this is because we load and activate egit core -> jgit here, *including* SSH init, therefore the time seems cumulative here for both. Delaying this will not help, the next JGit class reference will trigger the same. The SSH init (and the following proxy init) can be probably done in a job, because on startup we usually don't immediately start pulls etc where ssh or proxy would be needed.
Moving the SSH setup into a job is... tricky. While it's true that we most probably don't need ssh right away, we also don't know when such a job would run and when it would have completed. In theory we should make all ssh operations wait for this job to have completed.
Moreover one would have to make sure that * this job doesn't run if the EGit core bundle is already being stopped (it's probably a rather bad idea to cause bundle activation of other bundles at that time) * this job is not left running after the EGit bundle has been stopped. Which gives rise to some "interesting" synchronization problems with the OSGi bundle management. Plus the also "interesting" problem of how to ensure that all ssh operations _are_ actually delayed until the job _has_ run, though that seems easy in comparison.
I think this is not worth it. On my Mac I see Egit core start times: setupSSH run synchronously inside start(): start takes about 135 ± 4ms, setupSSH consumes about 25 ± 2ms. setupSSH run in a job scheduled from start(): start takes about 132 ± 7ms, setupSSH reports between 4-25ms (don't know why the variance is that high).
Timings obtained not via a profiler but by adding long start = System.nanoTime(); at the top of the operations, and System.out.println("start(): " + ((System.nanoTime() - start) / 1000.0) + "µs"); at the bottom, and then starting a runtime workbench (Photon) multiple times.
On my personal system I also don't see that much of an improvement (by moving only the SSH config into a job). I have to measure again on my company laptop. There the SSH initialization and the proxy configuration go together and that may explain the difference. If I see a reasonable decrease in start time by moving both to a job, then we can think again how to make that safe. If I don't manage to get the time down, then we can probably close this issue, as there have been quite some reasonable arguments why it is not that simple.
Cannot really see any improvements by moving the proxy and ssh initialization.
