2 weeks, 3 days ago
Looks fantastic, couldn't expect anything less from you Simon! Is that a custom GUI library of yours?
2 weeks, 2 days ago
Thanks. The GUI is custom code, but I wouldn't call it a library.
1 week, 6 days ago
Awesome! If you're planning to make it publicly available at some point, do you expect you'll ever document the file format?
I find it frustrating that every profiler comes with its own application-side header/code/library and would be interested in a setup where a default is provided but the format is also documented so I can write my own. This would be useful if (for example) I'm using an unsupported language, have a different environment or requirements or have some existing profiling infrastructure in place in my code and I want to try out your profiler for visualisation.
I suppose it'd be similar to how people have started using chrome's performance visualisation tools for all sorts of things that are unrelated to chrome just because it has a simple data format and you can give it whatever data you want.
On the other hand maybe this is just me being lazy and not wanting to figure out the format of other tools from their application-side libraries/headers!
1 week, 5 days ago
I'm not sure if or when I'll be releasing it. I would like to release it but I'm kind of afraid of having to provide support for it. We'll see.
The idea at first was to only return memory to the user so that they could write it to a file the way they wanted (there was only the header at that time, the GUI came later). But it was annoying having to write the "write to file" code when I wanted to quickly profile something, so I added a default write to file function in the header while still keeping the other method available. But yes, I will provide documentation for the "file format".
Note that the header file provides some functions to create the "event trees" out of the "event streams" and functions to iterate over them.