search

godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.07k stars 69 forks source link

Profiler update suggestions #2045

Open chucklepie opened 3 years ago

chucklepie commented 3 years ago

Describe the project you are working on

2d platformer

Describe the problem or limitation you are having in your project

Profiler limitations

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Using the profiler I'm finding features I wish was there as they're slowing things down or simply missing from what I'd hope most people would like in the profiler.

  1. Provide ability to profile more than 10 seconds as it seems to wrap just the last 10 seconds
  2. Provide a zoom so you can more easily go to the exact frames you want as sometimes with the screen constraints it's quite small
  3. Automatic profiling to filter or highlight sections that consume large amounts of frame time making it easier to find 'self' problems
  4. A lot of the time the fault is not in own code, e.g. I get 900% 'physics' for the first half second of loading a scene, it would be nice to have a breakdown of what is happening inside the system entries, e.g. what is actually taking up 900% physics other than simply showing the ':O' emoji ;-)

As example below, it's hard to go to the exact lag spike visually, there is nothing to tell me what the system is doing with 616% physics time and I'm limited to 10 seconds of view time.

image

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

As above, updated profiler abilities

Is there a reason why this should be core and not an add-on in the asset library?

debugging lag is hard, the profiler is the only tool and is lacking.

EricEzaM commented 2 years ago

See also #4139

the-sink commented 2 years ago

A lot of the features mentioned here would be great quality-of-life improvements for the profiler. I was honestly pretty surprised to see I can't zoom/pan around the profiler graph, it'd be very useful to help in investigating specific lag spikes.

More detailed profiler information on these categories would definitely be useful as well, as was mentioned; simply seeing that the physics frame time is occupying a large portion of the overall frame time is not enough information to be of any use in many scenarios. And it's especially annoying to have a major lag spike happen, but can't pause/stop in time and miss it as it vanishes beyond the 500 or so frame threshold. Longer profiler history would help with that!

Calinou commented 2 years ago
  1. Provide ability to profile more than 10 seconds as it seems to wrap just the last 10 seconds

The value is set here (the default is 600): https://github.com/godotengine/godot/blob/1f690f197a4fb0809afb2f59bf78e4d3d89fd847/editor/debugger/editor_profiler.cpp#L663

We should try to allow using greater values (up to 10000 maybe), then using a greater value by default (2000 or so).

Edit: Done in https://github.com/godotengine/godot/pull/61481.

  1. A lot of the time the fault is not in own code, e.g. I get 900% 'physics' for the first half second of loading a scene, it would be nice to have a breakdown of what is happening inside the system entries, e.g. what is actually taking up 900% physics other than simply showing the ':O' emoji ;-)

This is because Physics Frame Time is under the Frame Time category, but I think it ought to be its own category (with Physics Time as a child). Physics Frame Time is expected to be almost always greater than Frame Time, so it'll display a percentage greater than 100%.

I took a brief look but didn't manage to actually separate Physics Frame Time to its own top-level category. If anyone wants to experiment with this, the default categories are defined here: https://github.com/godotengine/godot/blob/1f690f197a4fb0809afb2f59bf78e4d3d89fd847/editor/debugger/script_editor_debugger.cpp#L613-L645

More detailed profiler information on these categories would definitely be useful as well, as was mentioned; simply seeing that the physics frame time is occupying a large portion of the overall frame time is not enough information to be of any use in many scenarios.

This is a known issue: https://github.com/godotengine/godot/issues/23715

hsandt commented 1 month ago

I'm specifically interested in point 4, as I have a resource loading spike lag and I need to identify the resource responsible for this, so I can preload it.

Maybe it's worth opening a separate issue for each point? I had a hard time finding this issue because the word "loading" is only present in description, not in title (so it showed in my search results but I had to manually look into every issue until I found this one).