-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Large projects seem frozen/crashed for several minutes on startup with poor editor feedback #47053
Comments
Related to #39841.
This most likely won't change until 4.0 (and even then, I'm not sure). The issue with performing importing in the background is that you can easily end up with an inconsistent state for resources, since the user will be able to open and edit scenes before everything is imported. However, parallel resource importing is planned to speed up the import process. |
I understand. My issue is not related to firsttime imports of resources or open scripts files. I close scriptfiles out of habit when I finish my workday to avoid any slowdowns. Even with 100+ scripts open on a busy day the restart of both pc and the entire Godot editor takes less than a minute cause everything is on a ssd. It is always only the firsttime editor start each day that bugs me cause it takes ages. Godot wants to reopen all the dusted, heavy 3D assets in the project folder for whatever reason and I can't understand why it must do that. Isn't the point of all those extra created import meta files and timestamps to avoid this constant reloading of heavy assets that havn't changed? |
After source scanning through a couple editor functions I think a general issue with the lack of feedback on so many ends is that most editor functions that display a progress (bar) run and update only with the process notification. Many of the problematic editor functions that take very long on large projects lock the entire editor until finished (no short waitusec or await in the loop). In this case a second frame that could show updated progress is never drawn cause the process notification is never send until the loop is finished. Without any frame updates for a few seconds e.g. Windows thinks that Godot has crashed when a user clicks on the window. |
Hi @smix8
The .import folder is about 3GB. |
That's surprising, as there's only a handful of commits between 3.3.1 and 3.3.2 and they wouldn't justify reimporting assets, as they don't invalidate previous imports. I just tried opening a fully imported 3.3.1 project in 3.3.2 and no reimport was caused. |
Yeah, suprised as I have around 100 MB of assets in my racer game, and dozens of scripts (probably somewhere in the vicinity of 50), and no reimport from 3.3.1. to 3.3.2, nor crashes. @skaiware: There were changes to FBX import recently, do you use any FBX assets? |
Hi @Zireael07, Tks, good catch, we have indeed in this project about 50 fbx files. |
@skaiware |
Bump. Bad UX on large projects still happens, both in 4.0 and 3.x (my racer project is enough to stall the loading noticeably, I dunno, 5-10 secs) |
Issue is still valid and more and more severe with growing project size. From limited profiling on Windows10 I learned that the EditorFileSystem functions are not the main issue. Godot afterwards gets stuck for multiple minutes due to sleep executions and thread waits. Most problems seem to come from So it seems to be a lock/thread issue that blocks the Editor from finishing after firsttime startup while it "does nothing". |
Do you know how to make those file open/read operations more efficient? If so, could you detail it here?
See #59787. Pull requests to make those use less CPU (and sleep when not required) are welcome 🙂 |
I don't think that export plugins is causing the perceive freeze here though. It's normal that you see those as active threads if you stop the execution at a given time and inspect all threads - but that doesn't mean that they're the ones blocking the main thread. |
Was this issue improved at all by #57766? |
That was only for the editor itself - I still see the stall caused by opening my main scene. |
I think this may have been effectively fixed by #57766, @Zireael07 project startup time is unrelated so I suggest you open a separate issue if you have a specific problem with running the project. |
I effectively solved the issue by changing the "main scene" that automatically opens to something less heavy :P |
This is still present in 4.2 beta3. This has been happening with an asset I put on the asset lib, which can also serve as a good reproduction project. Steps to reproduce
|
I tested a new project with https://godotengine.org/asset-library/asset/1653 With this PR #92650 it fixes the problem that the editor is frozen on start. I was able to reproduce the problem that in takes longer after a fresh reboot. The problem comes from the cache validation which opens all the .import files on startup. I did a couple of tests and I saw the process MsMpEng.exe spikes in CPU usage when starting the project after a fresh reboot. I added the project folder in the Windows Defender exceptions, and now even after a fresh reboot, the project loads really fast. I don't think Godot can do anyway about it except not rescanning the cache on startup, which does not seems a good idea. Maybe an option to skip the cache validation on startup could be added with an option to manually force a full rescan for large projects? What takes time is not really findings all files, it is to read the .import file and validate the cache. |
We should document this somewhere, probably on the Troubleshooting and Import process pages. Any other locations where we should document this? |
I am on Linux so my issue is definitely unrelated to MsMpEng.exe which is a part of Windows Defender |
Reopening as #92650 was reverted for 4.3. |
@smix8 If the issue is still present it will confirms that the source of the problem is the last modified date. |
@Hilderin
to the ProjectSettings before starting it. It made no difference as Godot would still load everything. |
@smix8 |
@Hilderin |
Maybe it because you have a ton of gbs worth of files, i doubt any engine can handle that pretty well, though can you try duplicating your project, deleting the .godot folder of that project and then start that one , then on second load it must be way faster to scan, just being the scene slowing you down. |
@smix8 Note: I also notice that loading a project for the first time in a day is a bit slower (not as slow as you are experiencing), I always tought it was the disk cache but maybe there's something else going on. |
Godot version:
v3.2.4.rc4.official
v4.x vulkan
OS/device including version:
Win10 64x
Issue description:
The editor seems to have a real struggle with very large Godot projects (50+ gb) ones per day on first startup.
I just clocked, the editor appears completely frozen/crashed for 7+ minutes on startup.
There is no feedback in both editor or console for users what is going on after the class_names and autoload scripts are successfully loaded.
There seems to be an issue with the file scanthread implementation. It seems the file scanthread has the desire to not only read all scriptfiles for changes but also open every single file each new day for no practical reason. As long as the scanthread is busy it blocks the entire editor until finished instead of working behind the scene.
The result is that the project appears nearly empty in the editor for a long time (shock moment, where are my files?) and also the editor stays unresponsive for several minutes as if it had a crash.
How to solve?
Steps to reproduce:
Create large Godot projects
Minimal reproduction project:
project size issue
The text was updated successfully, but these errors were encountered: