Theia: [electron] improve startup performance

[vince-fugnitto]

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 :smiley:

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|

[akosyakov]

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

[akosyakov]

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]

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).


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

[akosyakov]

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

[akosyakov]

probably https://github.com/theia-ide/theia/issues/3413

[vince-fugnitto]

@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]

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]

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]

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]

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?