Profiler update suggestions

[chucklepie]

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.

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]

See also #4139

[snibk]

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]

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 godotengine/godot#61481.

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 ;-)

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: godotengine/godot#23715

[hsandt]

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

[jakkarn]

Zoom feature would be the highest on my wishlist. I find it incredibly hard to find things that happen only one frame atm. It's mainly because you have to be able to put your mouse pointer accurately on a single pixel. Bigger frames should be default in the UI. maybe just increase the size and add a scroll bar?

The frame-step buttons are hard to use as well which makes it even more important. The buttons should be horizontal, not vertical, they are too small and they don't give any highlight feedback to let you know that you are clicking the correct button. Because of this, there is no good way to select a frame.

The solution made in the above mentioned link seems good and quite simple to fix.
godotengine/godot#76055

[laurentsenta]

Showing the graph's value on mouse hover would also make it much easier to find and drill down frames we care about,
example: https://d3-graph-gallery.com/graph/line_cursor.html

[Picorims]

Is there any chance that the vertical zoom could be implemented as well? When there is a huge spike, the graph is pretty much empty, and relying only on the table is very tricky:

Maybe some ways to update the min and max?

[Calinou]

It should be straightforward to implement this following godotengine/godot#76055. The hardest part is finding the UI for it (probably Shift + mouse wheel for vertical zoom, Shift + mouse motion for vertical pan).

Also, with vertical zoom, we'll want to have some kind of grid display even more so you're aware of the current zoom level.

[Picorims]

I think just some min/max inputs somewhere in the top bar would be enough for a first iteration, but yeah shortcuts and a grid would definitely improve the experience.

[TheJackiMonster]

Also at the moment in Godot 4 when you stop the profiler and check "Script functions" it scales down all graphs nearly to zero in my current project because it seems to visualize them in some weird normalized way which corresponds to all checked values (I really don't understand how it's calculated without looking into the source code).

I don't think this behavior is intended and I think in Godot 3 it doesn't behave like that either. So if someone is adding changes to the profiler tab, they should probably look into this weird behavior of scaling graphs as well.