Slow Godot opening(6s) due not caching data

[qarmin]

Godot version: 3.2 RC 1

OS/device including version: Ubuntu Mate 19.10 Intel i3 2330m HD 3000

Issue description: On my laptop Godot opens in 6 seconds, which seems to be fast, but I think that we can get lower time. Using Valgrind, Callgrind or GCC/Clang sanitizers cause that Godot opens 2x or even slower for some people.

I checked calls with Hotspot software available for Linux which use perf tool - https://github.com/KDAB/hotspot/releases

Project which I checked, contains only project.godot file, and I opened it more than once before(so cache should be active)

EditorHelp::generate_doc() - use almost 25% cycles and it can be split at two parts DocData::generate() - 17% and DocData::load() - 7%. If I'm correct, then DocData generate each time same data every time when opening Godot and DocData loads results.

Godot execute twice(I don't know why) function create_edtior_theme(5,6% and 6,11%), which generates almost same editor icons each time. Most time this function spends in ImageLoader::_create_image().

There is also ProceduralSky::_update_sky function which execute ProceduralSky::_create_sky(8,14%) which generate Sky, which isn't cached or saved anywhere.

I think that that Sky and Editor theme should be cached, and cache should be checked/updated after every change of Godot version.

I think that docs should be also saved to file, but also I think that generation of docs should be run on different thread and until ends, script tab should be disabled.

Project manager opens in 2s, which is really fast, but there 2x create_theme take almost 44% of time. Probably Godot create every single icon, even if there are not used in Project Manager

[Calinou]

Most time this function spends in ImageLoader::_create_image().

The SVG -> raster icon conversion takes a while. We could possibly cache the result on disk, but loading all the icons from disk may prove slower on HDDs (not sure).

[clayjohn]

There is also ProceduralSky::_update_sky function which execute ProceduralSky::_create_sky(8,14%) which generate Sky, which isn't cached or saved anywhere.

I have often wondered about this too. Although, instead of creating a caching system for procedural sky, we should just be switching to a default PanoramaSky (which is loaded from disk).

[Calinou]

@clayjohn That makes sense, but it means we need to embed one in the Godot binary or include one in every newly created project. However, HDRIs easily get quite large (though a simple gradient will likely compress well).

[Zireael07]

Would a Procedural->Panorama by default change affect projects which already use Procedural sky? I don't think it would speed up opening existing projects, y'know...

[clayjohn]

Would a Procedural->Panorama by default change affect projects which already use Procedural sky? I don't think it would speed up opening existing projects, y'know...

The difference is that the procedural sky has to generate the entire sky at load time (not sure how long it takes) and then generate radiance and irradiance maps (which right now take ~200ms). If we switched to a PanoramaSky, that could all be cached and it would just be a matter of reading from disk.

[Zireael07]

1) I know what the difference is, but I asked if it would speed up projects using proc sky. 2) Panorama sky is nice, but the procedural sky, has the advantage that you can have a day-night system fairly easily (by varying the sun position and colors). Is there a way to achieve the same with a panorama sky based setup?

[clayjohn]

Is there a way to achieve the same with a panorama sky based setup?

No. But that is besides the point, this issue is about reducing startup time for the editor. Right now a new procedural sky is generated even for users who are working on 2D projects. This change would only affect the default_env. It has nothing to do with using a ProceduralSky vs PanoramaSky in a regular 3D scene.

[Zireael07]

Aaah, ok, I get it. Good to know we're speeding up! <3

[Calinou]

@clayjohn For people working on 2D projects, this can already be achieved by removing the default_env.tres file. It requires the user to actually do it though :slightly_smiling_face:

[qarmin]

Now with Godot 4.0.dev.custom_build. c9e1d98c6 Editor opens on i7 4770k and SSD Drive in 5.632s(empty project opened with command godot -e --quit) Most of the time takes shader compilations(62,5% ~ 3.5s) which mostly works on only one thread which I think will be fixed later.

[qarmin]

Strange that in Project Manager there is allocated World3D(5MB memory not so much) It is really needed there?

[clayjohn]

I think it is needed for the default environment which is always loaded right now.

I think when we make our changes to how the default environment works for 4.0 this won't be an issue.

[qarmin]

Closing in favor of #43351 because this issue was mainly created for 3.2 branch and since then opening times was improved