Opened 6 years ago
Last modified 5 years ago
#5263 new enhancement
rmgen profiler
Reported by: | elexis | Owned by: | |
---|---|---|---|
Priority: | Nice to Have | Milestone: | Backlog |
Component: | Maps | Keywords: | |
Cc: | Patch: |
Description (last modified by )
In #4950 a random map script performance logger was introduced. But it only prints the data in chronological order to stdout / mainlog.
There are at least two use cases not covered by that:
- Finding the slowest calls (i.e. the most important ones to improve)
- A graph allowing visual performance comparison of the different calls (i.e. finding all important calls to improve)
The current rmgen logger output is easy enough to read for maps with few code (< 400 lines, most current maps), but warrants a better solution for complex code (> 1000 lines, new maps).
As we already have two profilers (see wiki:EngineProfiling), the first consideration must be an integration of rmgen performance into the existing solutions, so as to prevent any duplicate implementation.
But we quickly find the Profiler1 data format to be lacking. It is a text file optimized to be human readable. It seems JSON or XML would have been better and the intermediate step extract.pl
with all its regex magic would be unneeded.
The text format is not really inviting to have a second table added.
Also the format is designed to measure each of the categories once per turn, but in the rmgen case each call is only done once currently, or multiple times but at arbitrary times if extended. The latter is true for Profiler2 too.
So the cleanest solution seems to be to write a custom minimalistic rmgen profiler that writes a JSON file that is displayed with a jquery graph equal to the replayprofile graph.
Attachments (1)
Change History (4)
by , 6 years ago
Attachment: | screenshot.png added |
---|
comment:1 by , 6 years ago
Description: | modified (diff) |
---|
comment:2 by , 5 years ago
comment:3 by , 5 years ago
This displays the current stdout output in the browser, allowing to fulfil the stated purposes more comfortably (finding the slowest parts in a map generation that should be fixed first).
Is the information it collects sufficient?
Nothing is unimproveable I suppose. One could collect further data than collected currently if it's useful. The patch so far described is only displaying it in the browser, similar to source/tools/replayprofile/
.
The C++ profiler2 used by the simulation and AI could be investigated for example. rmgen is JS code, so it would have to involve the JS Interface MapGenerator.cpp to start and stop the profiler somehow, and rework the thing to not be c++ scope based. From what I read it doesn't hardcode simulation turn numbers, so it maybe doesn't need much rewrites. One could possibly track the number of library function calls. (I didnt get the question, but maybe I said something useful incidentally)
At first I think I misunderstood and thought this ticket was saying the current profiling tools aren't giving enough information, but I think I might be wrong about that.
Is this ticket just talking about the output of the profiles not being useful? Is the information it collects sufficient?