Ok, so this might not be the most glamorous plugin in the world, but it’s useful.
The idea of this plugin is that it will be able to create a profile of the engine and game (and other plugins) in order to tell you how much time is spent in what parts, helping to identify bottlenecks.
So, let’s talk about the aim of this little beast. Starting at the beginning of the minimum functionality then.
- Simple plugin that, when found in the Maratis “plugin path” will spew the time spent in each function in Maratis Engine/Core/Gui/Editor/Player to stdout.
- Simple config file and ability to output to stdout and/or file (on close)
- MGui popup window with profiling information displayed in real time
- Ability to track memory usage, creating a second tab for the MProfiler window
- If I get to this stage, might be nice to generate graphs, have config options in another tab etc.
Now, for something which doesn’t add directly to the game I’m making, this seems like a lot of work. However, it’s something I think will will be both useful for the game, but also for testing the plugin architecture and workflow. Things like working out a standard way to sort the plugin UI, doing a relatively easy plugin, seem like a good way to start things.
Starting at the beginning then, it’s probably quite obvious that I haven’t split up how to make the profiler at all. There’s a very simple reason for this. That is that I don’t plan on writing one. In fact. I’ve basically already completed this stage. I have chosen to use Shiny Profiler as the base for this plugin. It claims to be lightning fast and well documented. We shall see.
So, the way that Shiny works is that it requires tags to be put into the source code, they are macros which will automatically interact with the profiler. In itself, it’s very simple to add to an existing project, the issue is that it’s not quite the design I had in mind. For this to work, shiny would have to be a library, compiled into Maratis. As we’re making a plugin which shouldn’t always be available, this seems like a bad plan.
I have had to do a little bit of surgery on the Maratis source code to get it to work, which I will explain in the next post, but the basics is that there is a MProfilerContext in Maratis Engine which is null by default and a series of macros which evaluate to nothing in release builds, but in debug builds look for a MProfilerContext and send information to it. The plugin then registers itself as the current profiler, when loaded, and awaits information to be poured it’s way.
Once that’s hooked up, every function within the Maratis code has to have these tags put at the beginning of them. This is a LOT of tedious work. I could probably write a script that does it, but I haven’t yet. I’ve done the majority of Maratis Editor and tested it to get some sensible numbers coming out. Just have all the other tags still to put in, then I can move onto part 2.
Shiny Profiler doesn’t sort memory profiling. I’ve found no libraries which would do that actually. That’s not too much of an issue, although it will take further Maratis source butchery. I’m also not sure, at this point, how the best way to do it is. Of course the way to sort it is to implement a custom new/delete. These can then do a similar thing to the tags and check if there is a current profiler. This has the main problem that there are potentially a lot of new/delete calls before the plugin gets initialised. I guess it’s not too much of an issue as, in general, people would be most interested in profiling the memory usage in their game, rather than the engine. Also, as it will be using the tags to provide the scope in the profiler and the engine will most likely be compiled without the tags, it’s only going to be relevant for the game-side stuff anyway.
If you want to grab the code, it’s up on Github, as usual, but it currently won’t work without some Maratis changes. Let me know if anyone’s interested and I’ll package them up for you and stick them somewhere.
Well, that’s about it for now. Does anyone have any comments? Much as I’ve done a little of this at work, I’ve been using systems that have already been set up, so I’m pretty much flailing in the dark here. But doing so happily.