Community
Participate
Working Groups
Lets continue the work of Bug 550136 here. I think we have less low hanging fruits but still a few promising areas we could improve.
To get your own startup times: Create the following .options file org.eclipse.core.runtime/perf=true # turn on debugging for the org.eclipse.core plugin. org.eclipse.osgi/debug=true Start Eclipse with eclipse -data yourworkspace -debug Please note that we optimized the warm start, e.g. you have to start Eclipse at least twice for the same instance and workspace. I use an empty workspace for testing
Eclipse SDK Version: 2020-03 (4.15) Build id: I20191211-1805 OS: Linux, v.5.3.0-24-generic, x86_64 / gtk 3.24.12 Java version: 12.0.1 with Git and Marketplace installed starts into an empty workspace: Debug options: file:/home/vogella/dev/eclipse-2019-12-11/eclipse/.options loaded Time to load bundles: 4 Starting application: 1037 Application started in : 5406ms
Lars, I think you should switch to 3.8.2 if you want *really* fast startup times. 4.6 - 4.15 starts all within ~3.5 - 3.7 seconds on my workstation, with no major difference in numbers, but with 3.8.2 on same system I'm at ~2 seconds. The major improvement in startup time is also at 4.x -> 3.x switch, not in 4.12, 13 or 14 release. So if you want really fast starting Eclipse, I would recommend 3.8.2 or try to remove e4 model related code from workbench :-).
Andrey, I find to hard to take something useful out your findings. Are you just trying to remind us of the good old times?
Traced Oomph installer startup times in the 1.15.0 Build 4434 as I was surprised that it takes almost as long as a full IDE .options file: # turn on debugging for the org.eclipse.core plugin. org.eclipse.osgi/debug=true # turn on execution time of the activator for the plug-ins org.eclipse.osgi/debug/bundleTime=true # turn on total execution time of the plug-ins org.eclipse.osgi/debug/bundleStartTime=true Startup: Time to load bundles: 5 Starting application: 952 Application started in : 4671ms Activator times 429 org.eclipse.oomph.setup.installer_1.15.0.v20191204-1132 182 org.eclipse.core.runtime_3.17.0.v20191122-2104 101 org.eclipse.oomph.setup.ui_1.15.0.v20191206-1128 88 org.eclipse.equinox.console_1.4.0.v20190819-1430 82 org.eclipse.osgi_3.15.100.v20191114-1701 76 org.eclipse.emf.common_2.17.0.v20190920-0401 74 org.eclipse.ui.workbench_3.117.0.v20191126-1131 69 org.eclipse.update.configurator_3.4.400.v20191122-2102 51 org.eclipse.equinox.simpleconfigurator_1.3.400.v20191015-1836 50 org.eclipse.oomph.p2.core_1.14.0.v20191209-1132 41 org.eclipse.core.jobs_3.10.600.v20191122-2104 40 org.apache.felix.gogo.runtime_1.1.0.v20180713-1646 31 org.eclipse.equinox.preferences_3.7.600.v20191017-2055 28 org.eclipse.equinox.registry_3.8.600.v20191017-2055 25 org.apache.felix.scr_2.1.14.v20190123-1619 24 org.eclipse.emf.ecore_2.20.0.v20190920-0401 21 org.eclipse.equinox.app_1.4.300.v20190815-1535 19 org.eclipse.core.net_1.3.700.v20191122-2107 14 org.eclipse.ecf.provider.filetransfer_3.2.500.v20191017-1905 12 org.apache.felix.gogo.shell_1.1.0.v20180713-1646 11 org.eclipse.core.contenttype_3.7.500.v20190916-2125 10 org.eclipse.equinox.common_3.10.600.v20191004-1420 10 org.eclipse.ecf_3.9.4.v20191020-1846 9 org.eclipse.oomph.setup.p2_1.13.0.v20191019-1424 8 org.eclipse.oomph.setup.core_1.15.0.v20191103-0619 7 org.eclipse.emf.edit.ui_2.17.0.v20190920-0412 7 org.eclipse.ecf.identity_3.9.300.v20191020-1846 6 org.eclipse.oomph.util_1.13.0.v20191110-1802 6 org.eclipse.oomph.ui_1.13.0.v20191116-1146 5 org.apache.felix.gogo.command_1.0.2.v20170914-1324 4 org.eclipse.equinox.p2.core_2.6.200.v20191014-1220 3 org.eclipse.ui_3.115.0.v20191127-1056 3 org.eclipse.emf.edit_2.16.0.v20190920-0401 3 org.eclipse.e4.ui.workbench_1.11.0.v20191120-1917 2 org.eclipse.oomph.setup.p2.edit_1.11.0.v20190702-1454 2 org.eclipse.oomph.base.edit_1.12.0.v20190702-1454 2 org.eclipse.equinox.security.ui_1.2.500.v20191003-0536 1 org.eclipse.ui.net_1.3.600.v20190925-1021 1 org.eclipse.oomph.setup.edit_1.14.0.v20190704-1252 1 org.eclipse.oomph.setup_1.15.0.v20191116-1146 1 org.eclipse.oomph.p2.ui_1.12.0.v20191206-0547 1 org.eclipse.oomph.jreinfo.ui_1.11.0.v20191006-0741 1 org.eclipse.oomph.jreinfo_1.11.0.v20190523-0419 1 org.eclipse.equinox.security_1.3.400.v20191008-0645 1 org.eclipse.equinox.p2.transport.ecf_1.2.300.v20191001-0955 1 org.eclipse.equinox.p2.repository_2.4.600.v20191016-0510 1 org.eclipse.equinox.p2.garbagecollector_1.1.300.v20191015-1207 1 org.eclipse.equinox.p2.engine_2.6.500.v20191014-1645 1 org.eclipse.equinox.p2.artifact.repository_1.3.300.v20191015-1504 1 org.eclipse.emf.common.ui_2.18.0.v20190507-0402 1 org.eclipse.ecf.provider.filetransfer.httpclient45_1.0.100.v20191012-1656 1 org.eclipse.ecf.filetransfer_5.0.300.v20191020-1846 1 org.eclipse.e4.ui.workbench.swt_0.14.800.v20190930-1643 0 org.eclipse.oomph.p2.edit_1.11.0.v20190323-1130 0 org.eclipse.oomph.base_1.12.0.v20190705-1018 0 org.eclipse.equinox.p2.director_2.4.500.v20191014-1220 0 org.eclipse.equinox.event_1.5.300.v20191001-1333 0 org.eclipse.emf.ecore.xmi_2.16.0.v20190528-0725 0 org.eclipse.core.expressions_3.6.600.v20191122-2104
With respect to the installer, that's no so surprising and not so relevant.
Status update: Eclipse SDK Version: 2020-03 (4.15) Build id: I20200120-1800 OS: Linux, v.5.3.0-26-generic, x86_64 / gtk 3.24.12 Java version: 1.8.0_232 Debug options: file:/home/vogella/dev/eclipse-2020-01-20/eclipse/.options not found Time to load bundles: 3 Starting application: 763 Application started in : 4098ms
is there also a case to look at the workspace/resources? Because for us that is i think the biggest performance problem that we have.. For example just make a simple workspace, where you put in a angular8 project that touches a few stuff (don't need to be that big i think a simple hello world example would already do it) then do npm install and npm run build on it.. That generates a huge directory in node_modules and that slows down eclipse a lot working with that, refreshing and so on. I always have a feeling that somehow eclipse must be smarter for this, it must not cache or rely on a abstraction on top of the actual file system that much. I know eclipse needs stuff for this for special things (like links and maybe even mapping zips?). But it would be nice to somehow be able to speed this up quite a bit.
(In reply to Johan Compagner from comment #8) > is there also a case to look at the workspace/resources? > > Because for us that is i think the biggest performance problem that we have.. > > For example just make a simple workspace, where you put in a angular8 > project that touches a few stuff (don't need to be that big i think a simple > hello world example would already do it) > > then do npm install and npm run build on it.. > > That generates a huge directory in node_modules and that slows down eclipse > a lot working with that, refreshing and so on. > > I always have a feeling that somehow eclipse must be smarter for this, it > must not cache or rely on a abstraction on top of the actual file system > that much. I know eclipse needs stuff for this for special things (like > links and maybe even mapping zips?). But it would be nice to somehow be able > to speed this up quite a bit. Johan, this sounds like a problem not related to startup. Are you using Wild Web Developer? If yes, please open a new issue for them
no we don't use that, its just plain eclipse and you use a product that has huge resources. Its really in the core.. I agree its not directly related to startup, (but such a project could really hurt stuff when starting up if eclipse thinks its needs to refresh directly after that) Eclipse itself just doesn't handle huge directories that well, a node_modules dir that you generate from an angular app is very quickly 500MB worth of files and dirs.. Problem is that file access is the one startup culprit of eclipse, i also profiled our product a bit more for this case, and pretty much all the huge stack traces to get the ui up and running kind of end up in File.exists() calls and things like that..
Johan, the right way to address your issue is to create new bug, provide steps to reproduce and ideally profiler results. If you are on Windows, you are most likely hit by antivirus mafia, but I would not like to discuss this on this ticket.
(In reply to Johan Compagner from comment #10) > Problem is that file access is the one startup culprit of eclipse, i also > profiled our product a bit more for this case, and pretty much all the huge > stack traces to get the ui up and running kind of end up in File.exists() > calls and things like that.. This open a separate bug for this issue. I also recommend to try out WWD, which is supposed to do almost everything asynchronously.
See https://community.sonarsource.com/t/sonarlint-slows-down-eclipse-ide-startup/19513 in which SonarLint moves to a Job, reducing its startup time contribution from ~650ms to ~40ms.
Thanks for everyone who work on this. Work continues via Bug 560449 for the 4.16 release.
