Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[electron] improve startup performance #5284

Closed
vince-fugnitto opened this issue May 28, 2019 · 10 comments · Fixed by #5386
Closed

[electron] improve startup performance #5284

vince-fugnitto opened this issue May 28, 2019 · 10 comments · Fixed by #5386
Assignees
Labels
electron issues related to the electron target epic epic issues consisting of multiple smaller issues performance issues related to performance

Comments

@vince-fugnitto
Copy link
Member

vince-fugnitto commented May 28, 2019

Description

This is an epic issue to discuss and tackle improving the startup performance for Electron.
Currently, starting an Electron application can take considerable time, therefore we should take measures to actively tackle performance issues on Electron, and consequently improve the overall performance and speed of the entire application.

Considerations

  1. lazy load components which aren't necessary at startup.
  2. improve minimization and compression.
  3. revisit references of initialize, initializeLayout and onStart.
  4. other ideas.

Steps to Reproduce

Created a streamlined Electron application (package.json) and build it using:

(yarn && yarn theia build --mode production && yarn theia rebuild:electron)
{
    "private": true,
    "license": "EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0",
    "theia": {
        "target": "electron",
        "frontend": {
            "config": {
                "applicationName": "Theia Electron"
            }
        }
    },
    "dependencies": {
        "@theia/core": "next",
        "@theia/editor": "next",
        "@theia/electron": "next",
        "@theia/file-search": "next",
        "@theia/filesystem": "next",
        "@theia/monaco": "next",
        "@theia/navigator": "next",
        "@theia/preferences": "next",
        "@theia/search-in-workspace": "next",
        "@theia/terminal": "next",
        "@theia/textmate-grammars": "next",
        "@theia/typescript": "next",
        "@theia/workspace": "next",
        "typescript": "latest"
    },
    "devDependencies": {
        "@theia/cli": "next"
    }
}

Results

Command Description # 1 (sec) # 2 (sec) # 3 (sec) Avg (sec)
yarn theia start Start application without a workspace 3.66 3.73 3.65 3.68
yarn theia start ~/theia-workspace-theia Start application w/ a workspace 15.45 12.91 13.12 13.83

The performance degrades as more extensions are present, and if a workspace is opened on start-up which leads me to believe there might be an extension which slows down the startup or waits for other contributions to be ready.

If anyone had ideas on how the performance can be improved, please let me know 😃

cc @marcdumais-work @marechal-p @lmcbout @thegecko @kittaakos


Updates

Type Scenario Time
onStart No Workspace 560 ms
onStart Workspace 17016 ms
Target Time
Browser time
Electron time
@vince-fugnitto vince-fugnitto added epic epic issues consisting of multiple smaller issues electron issues related to the electron target performance issues related to performance labels May 28, 2019
@akosyakov
Copy link
Member

Please check console logs. If some contributions exceed 200ms they should be reported.

@akosyakov
Copy link
Member

Considerations:

  • lazy load components which aren't necessary at startup.
  • improve minimization and compression.
  • revisit references of initialize, initializeLayout and onStart.
    other ideas.

Measure and find a real root cause :)

@vince-fugnitto
Copy link
Member Author

Please check console logs. If some contributions exceed 200ms they should be reported.

These are the results I got when executing (yarn theia start ~/theia-workspace/theia).

image

I get the root WARN e.onStart is slow twice,
one for 198.7000000081025 ms and the other for 10903.599999961443 ms

@akosyakov
Copy link
Member

@vince-fugnitto please compile in development mode, to see what e stands for

@akosyakov
Copy link
Member

probably #3413

@vince-fugnitto
Copy link
Member Author

@vince-fugnitto please compile in development mode, to see what e stands for

The first is LanguagesFrontendContribution.onStart and the other is EditorNavigationContribution.onStart.

@akosyakov
Copy link
Member

Now you should use the node profiler to record CPU snapshot during start up and analyse call-stack for these methods to see where time is actually spent.

@vince-fugnitto
Copy link
Member Author

Now you should use the node profiler to record CPU snapshot during start up and analyse call-stack for these methods to see where time is actually spent.

Thank you for your help @akosyakov, I'm still learning on how to profile and everything so I appreciate the guidance.

@kittaakos
Copy link
Contributor

Now you should use the node profiler to record CPU snapshot during start up and analyse call-stack for these methods to see where time is actually spent.

You might have to modify the generated electron-main JS as we do not want to profile the electron process but the backend process forked from the electron-main. Now, here it gets tricky, as we run the code differently for a bundled electron application and for the development environment. If you want to profile the backend process, you have to pass the --prof into the forked process as a execArgv. See here. Final words, before you get into any deep profiling, please check if you can see any startup time improvements with #4869. I had a much better user experience on that branch.

@vince-fugnitto
Copy link
Member Author

Final words, before you get into any deep profiling, please check if you can see any startup time improvements with #4869. I had a much better user experience on that branch.

Would it be possible to finish the review and merge #4869 to increase the user experience, perhaps after the release?

@kittaakos kittaakos self-assigned this Jun 6, 2019
kittaakos pushed a commit that referenced this issue Jun 6, 2019
At application startup, we send out a couple thousand preference change
events. Each of them triggers a menu update. It semms to be expensive.
Debounced it.

Closes #5284.

Signed-off-by: Akos Kitta <[email protected]>
kittaakos pushed a commit that referenced this issue Jun 6, 2019
At application startup, we send out thousands of preference change
events. Each of them triggers a menu update. It seems to be expensive.
Debounced it.

Closes #5284.

Signed-off-by: Akos Kitta <[email protected]>

s

Signed-off-by: Akos Kitta <[email protected]>
kittaakos pushed a commit that referenced this issue Jun 7, 2019
At application startup, we send out thousands of preference change
events. Each of them triggers a menu update. It seems to be expensive.
Debounced it.

Closes #5284.

Signed-off-by: Akos Kitta <[email protected]>

s

Signed-off-by: Akos Kitta <[email protected]>
marcdumais-work pushed a commit that referenced this issue Jun 13, 2019
At application startup, we send out thousands of preference change
events. Each of them triggers a menu update. It seems to be expensive.
Debounced it.

Closes #5284.

Signed-off-by: Akos Kitta <[email protected]>

s

Signed-off-by: Akos Kitta <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
electron issues related to the electron target epic epic issues consisting of multiple smaller issues performance issues related to performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants