Bugzilla – Full Text Bug Listing
| Summary: | Improve startup up time of Marketplace client | ||
|---|---|---|---|
| Product: | [Technology] MPC | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | Install | Assignee: | Project Inbox <mpc.install-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.blewitt, karsten.thoms, Lars.Vogel, leif.geiger, reckord |
| Version: | unspecified | ||
| Target Milestone: | 1.9.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168703 https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168701 https://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=0d8562954756146de11cdd9a55fe37269bfad1e1 https://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=f99217c40d0d662d9074619719d4127c7de09e09 |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 566485 | ||
|
Description
Lars Vogel
Those startup times are rather misleading. They include startup times of bundles we depend on (the hugest chunk being core.net and p2) and highly depend on your IDE's startup order. E.g. in the installation I use productively, those times are "only" around 150ms, because P2 is already started before MPC. You can see the startup times of dependencies in the full startup trace logs. Subtracting those times, MPC only spends around 7-8ms in its own startup code on my machine. From playing around with my installation and disabling various things in MPC and the IDE as a whole, I don't think removing those two "inner" startups in MPC will have much of an impact on overall startup time, since they will come up in other places. However, I've still looked into refactoring the code that requires core.net and p2 to be initialized during startup. Unfortunately, that won't work without changing service registrations that I would consider public MPC API. Because of this, and because of the dubious effect it will have on overall startup time, this hasn't been too high on my priority list. I apologize for not giving an explanation for this in a more timely fashion. Carsten, what is the reason that the MPC must start at all via its activator? Should it not only be triggered once I open it via the menu? (In reply to Carsten Reckord from comment #2) > Unfortunately, that won't work without changing service registrations that I > would consider public MPC API. To explain further: MPC does some dynamic registration of its exposed services at startup time, among other things based on some core.net and p2 state. I don't see a way to use declarative services (which are initialized lazily) in MPC here, because I don't know of a (clean) way to make those conditional on external factors that aren't evaluated early. However, the issue here stems mostly from backward compatibility code that provides legacy API and fallback services for when P2 transports aren't available. It should be unproblematic to remove those altogether, or bundle them up in a fashion that allows for lazy initialization. That will require breaking some official (the list of services exposed by MPC) and some internal API that we so far have tried to keep stable. So I am a bit hesitant to do that now, when the use is a bit dubious, and while we are still lining up other changes that will require breaking changes with much higher usefulness. (In reply to Lars Vogel from comment #3) > Carsten, what is the reason that the MPC must start at all via its > activator? Should it not only be triggered once I open it via the menu? The reason is the dynamic service registrations that it does, and that I haven't found a way to do declaratively. (In reply to Carsten Reckord from comment #5) > The reason is the dynamic service registrations that it does, and that I > haven't found a way to do declaratively. (Essentially, it checks if certain P2 things are present, and then registers one service, and otherwise registers a bunch of alternative ones) And no, it can't just start via the menu, because it has to hook up some other things as well in UI via early startup, that will inevitably initialize mpc.core as well (drag&drop support mainly). Could you move the registration into a job? Sonar for Eclipse did that and improved startup time by ~600ms IIRC. This way the trigger to core.net and p2 would outside of the main thread and not block startup. See https://www.vogella.com/tutorials/EclipsePerformance/article.html#example-tracing-the-startup-time-of-plug-ins for extracting the numbers via OSGi tracing. In an SDK with Git and Marketplace p2 and core.net do not consume a lot of time. See https://wiki.eclipse.org/StartupTimesOfBundles The job approach would leave MPC in an undetermined state between bundle startup and job completion, which would also be a breaking change with at least theoretically problematic or API breaking consequences. I don't think any of the possible solutions would really cause any problems with MPC itself that couldn't be easily remedied, but there are at least few cases out there of clients consuming our API (not as many as other projects, but still...) and this could be a problem there. My suggestion would be to revisit this early in the 2020-09 cycle, so if breakage cannot be avoided, there's enough lead-up time. Also, by then, we might have a better idea of what other breaking changes we might want to ship in the foreseeable future and align those better. 2020-09 sounds great. New Gerrit change created: https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168703 New Gerrit change created: https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168701 Gerrit change https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168701 was merged to [master]. Commit: http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=0d8562954756146de11cdd9a55fe37269bfad1e1 Gerrit change https://git.eclipse.org/r/c/mpc/org.eclipse.epp.mpc/+/168703 was merged to [master]. Commit: http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=f99217c40d0d662d9074619719d4127c7de09e09 Very nice, with this change, the reported activator times for MPC are now very small. Activator times 345 org.eclipse.jdt.ui_3.21.200.v20200828-0853 208 org.eclipse.jdt.core_3.23.0.v20200828-0941 197 org.eclipse.egit.ui_5.9.0.202008260805-m3 146 org.eclipse.egit.core_5.9.0.202008260805-m3 111 org.eclipse.core.resources_3.13.800.v20200706-2152 80 org.eclipse.emf.common_2.20.0.v20200822-0801 69 org.eclipse.equinox.simpleconfigurator_1.3.600.v20200721-1308 63 org.eclipse.osgi_3.16.0.v20200828-0759 53 org.eclipse.ui.trace_1.1.800.v20200106-1301 51 org.eclipse.equinox.console_1.4.200.v20200828-1034 51 org.eclipse.core.runtime_3.19.0.v20200724-1004 49 org.eclipse.update.configurator_3.4.600.v20200422-1910 44 org.eclipse.ui.workbench_3.120.0.v20200829-1411 42 org.eclipse.equinox.app_1.5.0.v20200717-0620 39 org.eclipse.e4.ui.workbench_1.11.400.v20200828-0938 37 org.eclipse.core.jobs_3.10.800.v20200421-0950 30 org.eclipse.jsch.core_1.3.900.v20200422-1935 30 org.eclipse.equinox.registry_3.9.0.v20200625-1425 28 org.eclipse.pde.ui_3.12.0.v20200824-1258 26 org.eclipse.core.net_1.3.1000.v20200715-0827 21 org.apache.felix.gogo.runtime_1.1.0.v20180713-1646 19 org.eclipse.emf.ecore_2.23.0.v20200630-0516 17 org.eclipse.pde.core_3.14.0.v20200817-1143 17 org.eclipse.jdt.launching_3.18.0.v20200824-1854 17 org.apache.felix.scr_2.1.16.v20200110-1820 13 org.eclipse.equinox.preferences_3.8.0.v20200422-1833 13 org.eclipse.equinox.common_3.13.0.v20200828-1034 11 org.eclipse.team.ui_3.8.1000.v20200806-0621 11 org.eclipse.equinox.p2.reconciler.dropins_1.3.400.v20200511-1530 10 org.eclipse.debug.core_3.16.0.v20200828-0817 9 org.apache.felix.gogo.shell_1.1.0.v20180713-1646 8 org.eclipse.team.core_3.8.1100.v20200806-0621 7 org.eclipse.equinox.event_1.5.500.v20200616-0800 5 org.eclipse.ltk.core.refactoring_3.11.100.v20200720-0748 5 org.apache.felix.gogo.command_1.0.2.v20170914-1324 4 org.eclipse.ui.navigator_3.9.400.v20200723-2304 4 org.eclipse.equinox.p2.core_2.6.300.v20200211-1504 3 org.eclipse.ui.workbench.texteditor_3.15.0.v20200812-2334 3 org.eclipse.jdt.apt.core_3.6.700.v20200828-0941 2 org.eclipse.ui.ide_3.17.200.v20200808-0622 2 org.eclipse.ui.editors_3.13.300.v20200812-2334 2 org.eclipse.ui_3.118.0.v20200807-0902 2 org.eclipse.pde.launching_3.9.0.v20200812-1037 1 org.eclipse.ui.navigator.resources_3.7.400.v20200722-0751 1 org.eclipse.pde.ds.annotations_1.2.0.v20200813-0526 1 org.eclipse.ltk.ui.refactoring_3.11.100.v20200817-1715 1 org.eclipse.jdt.apt.pluggable.core_1.2.500.v20200322-1447 1 org.eclipse.help_3.8.800.v20200525-0755 1 org.eclipse.equinox.p2.ui.sdk.scheduler_1.4.800.v20200731-1005 1 org.eclipse.equinox.p2.engine_2.6.700.v20200511-1530 1 org.eclipse.epp.mpc.ui_1.8.5.v20200902-1804 1 org.eclipse.emf.ecore.xmi_2.16.0.v20190528-0725 1 org.eclipse.e4.ui.workbench.swt_0.14.1100.v20200619-0644 1 org.eclipse.core.filebuffers_3.6.1000.v20200409-1035 1 org.eclipse.compare.core_3.6.900.v20200412-2017 0 org.eclipse.ui.views.log_1.2.1200.v20200828-0938 0 org.eclipse.tips.ide_0.1.900.v20200522-1444 0 org.eclipse.jdt.core.manipulation_1.14.100.v20200817-2001 0 org.eclipse.equinox.security_1.3.500.v20200114-1637 0 org.eclipse.equinox.p2.repository_2.4.800.v20200813-0739 0 org.eclipse.epp.mpc.core_1.8.5.v20200902-1804 0 org.eclipse.e4.ui.css.swt_0.13.1100.v20200819-0632 0 org.eclipse.core.variables_3.4.800.v20200120-1101 Thanks, Carsten. Can this bug be closed? *** Bug 558413 has been marked as a duplicate of this bug. *** |