Exporting to other formats

[wouterrvdb]

I really like the simplicity of easy_profiler, but as far as I know you can sadly not use the generated data for other applications. I think it would be nice if you would be able to export (a subset of) the data to other formats, such as .json or .csv. Perhaps you would even be able to indicate which data you would like to export. This could be useful for e.g. marketing purposes, because the amount of information generated by easy_profiler is a bit overkill when it comes to communication with third parties.

[rationalcoder]

Why not just write a third-party parser? The format is now documented over on the wiki. What specific use case did you have in mind? I guess there could be plugin support in the GUI for exporters? If this turns out to be a reasonable idea, I wouldn't mind doing this myself. Personally, I think the profiler_reader program could be extended to offer a general format conversion API that could be used for such purposes.

[wouterrvdb]

My apologies, I was not aware that the format was actually documented on the wiki, which would make third-party parsing a viability indeed. However, to me the appeal of easy_profiler is that it's, well, easy. It's very straight-forward to use and with a few lines of code you can have a nicely detailed overview of a code profile. Its simplicity, however, does not translate well to external communication: if you e.g. want to show off your program's speed (by itself, or by comparing it with previous iterations or with competitors), then as far as I'm aware easy_profiler offers no real solution; you can either screenshot the existing graphs (which are useful but ugly for marketing purposes) or decide not to use easy_profiler and simply measure the times manually, which feels like wasted work. This is only one use case, but I'm sure that there are many others which would benefit from an export functionality. Personally, I can't think of a reason not to offer this functionality, besides the fact of course that it costs time and energy which you might want to use to improve other parts of the project.

I agree with you that offering an API would probably be the best solution: people would still be free to write their own, private third-party parsers, and enthusiasts could easily write a parser that could be plugged into easy_profiler. Either way, it would be more user-friendly.

I don't mind helping out with this myself, but I am not sure how much time I would be able to dedicate to it.

[rationalcoder]

Well, I guess that is why it is called "Easy Profiler" and not "Easy Profiler/Marketer" ;) On a more serious note, you still haven't mentioned explicitly what information you are wanting to pull out for marketing purposes. What would the interface for a plugin style exporter look like?

I'm thinking there should be a general libeasy_file sub project that provides a nice API for .prof files along with a super basic exporter plugin API that the GUI understands. That way, there can be an "Export with" option in the GUI that lists the available exporter plugins. The exporters themselves could be built with the libeasy_file library and go nuts. Although, all of that might be overkill in favor of a command-line project that can provide diffs between .prof files by block name. This needs more discussion.

[cas4ey]

@wouterrvdb Well, exporting to other format is a good point 👍 Me and @yse keep coming back to that idea from time to time :) You can help with creating plugins.

As @rationalcoder mentioned, there is a documented file format and I like the idea of creating an extensible importer/expoter lib which could then use custom plugins to make export and import.

[yse]

When we start this project the main purpose was to create extremely small memory usage tool (both RAM usage and profiling result at hard disk usage). In case of some text format - it will be a very large for pretty much block's count. At first step, I think, converter from prof format to anyone else (e.g, callgrind) will be useful. And of course json-format with schema will useful for understanding all capturing data.

[rationalcoder]

@yse It is my understanding that he doesn't necessarily want a textual format, just a nice API for pulling data out of a .prof file for comparison with another. Keep in mind that if you do this it should be a simple C API, not an over-complicated C++ one, that is separate from easy_profiler_core. That way, current code can be left alone and the API will be portable and easy to understand.

[yse]

@rationalcoder yes, of course. Evidently current API is not so suitable for understanding :-| There is only one function with no clear parameters. I think API will be improved with creating much more parsers (_profilerreader was a sample of parsing data from prof-file, but...unfortunatly was abandoned with unknown reasons)

[wouterrvdb]

@rationalcoder Your understanding is indeed correct! And with this, building parsers into the GUI should be very simple as well, which is what I was trying to achieve by opening this issue.

[mmatrosov]

I would like to comment that I spent quite some time trying to understand how to generate JSON/CSV or even HTML report from the easy profiler data file. I was very surprised once I realised this is not possible. I think this is like a feature anyone would expect to see. Currently, this is the only feature that EasyProfiler lacks comparing to our own (not so good) hand-made profiler, and the only reason which prevents us from switching to EasyProfiler completely.

[yse]

@mmatrosov thank you for feedback! We have an experimental tool (see PR #87) for generating json-formatted report. I think it will be merged in near future and you will be able to work with text output.

[mmatrosov]

Great to hear that! Will look forward to it :)

[yse]

@mmatrosov we have merged command line tool. For converting to json format you should checkout new develop, build it and run profiler_converter like:

./bin/profiler_converter INPUT_PROF_FILE

and it will dump to stdout json with measured values. If you will have some issue related to converter - please create a new issue =)

[gggin]

After some time, do you have time to implements a feature from #69 , just a suggesttion. maybe a Valgrind call graphics, so we can statically get all function run times.