godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.52k stars 21.26k forks source link

Benchmark functions for timestamp calculating #27150

Closed Chaosus closed 4 years ago

Chaosus commented 5 years ago

Godot version: 3.2

OS/device including version: all

Issue description: My proposal is to add few built-in functions into core. One is called something like bmark_start - and it will internally creates a timer(with higher precision on provided system such as QueryPerformanceTimer on Windows) and second is bmark_stop - which will stop the timer and return a string contained timestamp result - something like this - "Timestamp : 0.000001" or "Timestamp: 00m:00s:0000ms:000100ns". This will allows user to easily calculates a timestamps and find the code which is more time-consuming. For example:

func test() :
  bmark_start()

  for i in range(10000):
    <some complex calculations here>

  print(bmark_end())

I know that simular functionality is exist in Profiler but it has several problems:

  1. Its not comfortable to use to measure call time of single function - cuz its counting all calls
  2. Its not possible to check just a part of the function - only full including a call delay itself
  3. Its not supporting calculating of other languages(and different platforms ?) - in the proposal C#, C++ and other(including even VisualScript) is supporting well I think only different platforms where profiler is not available
  4. Its not retrieve a string to print it to output or saved into file
isaacremnant commented 5 years ago

I always liked Matlab's short tic/toc so I put this in an autoload

var tic_time = 0.0
func tic(): tic_time = OS.get_ticks_msec()
func toc(): print("Elapsed time: %dms"%(OS.get_ticks_msec() - tic_time))

The disadvantage as you said is precision, but it's probably better to run a test for a few seconds anyway. Still would be nice to have high precision built-in timestamps.

Chaosus commented 5 years ago

Yeah, the disadvantage of creating it manually besides a precision is just a fact that its non-ellegant (you should create it in autoload, or static class in every project where you want this functionality)

Zylann commented 5 years ago

In my benchmark suite I actually encapsulated this outside my tests, so I didnt even need to write it again for each test. Otherwise, I usually write this similar logic:

var time_before = OS.get_ticks_usec()

for i in ITERATIONS:
    # Stuff

var time_spent = OS.get_ticks_usec() - time_before
print("Stuff time: ", time_spent)

In my benchmark suite, I do eventual calculations on time_spent and either print it, or store it in a JSON file for later display in a summary tool, so bmark_* would not be of any help due to returning a string which I would have to parse to do something useful with it.

However It can be useful as a quick temporary test on production code, it saves from having to create an autoload doing the same thing. But honestly I always did the snippet above without thinking about making a helper^^

As for Profiler... I'd be interested to profile sections of code still, but is it even available to GDScript? I can't find it when searching the doc.

isaacremnant commented 5 years ago

@Zylann didn't know about usec, thanks! Gonna change my helpers. Do you know the uncertainty in microseconds though? I was under the impression that timing below ms was iffy due to timing issues and whatnot.

edit: It uses clock_gettime on unix so precision should be good.

Zylann commented 5 years ago

@isaacremnant usec should use the high resolution counter, but I can't check easily right now, I'm on a phone

clayjohn commented 4 years ago

I think a lot of this may be addressed by the "custom profiler" GSOC project!

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

Zylann commented 4 years ago

I think a lot of this may be addressed by the "custom profiler" GSOC project!

From what I read of the project, it doesn't really adress the time measuring part, but more the way it gets reported. It is named "custom profiler" but in reality it's more like custom monitors. I have an advanced CPU-time profiler prototype in the works for Godot and at least that was the conclusion I came to when I had a look at the existing GSoC project. (correct me if I'm wrong?)

clayjohn commented 4 years ago

@Zylann I don't know enough about the current project to say. It would be worth checking in with someone who knows more though!