Iterate over recorded bocks "by hand"

[Jochen0x90h]

Is it possible to iterate over the recorded bocks "by hand" and e.g. dump info to std::cout? This way it would be possilbe to print simple statistics on program exit to the console, e.g. containing percentage, number of calls and total time used for each block

[cas4ey]

Hi @Jochen0x90h

Currently the only way to do it - is to dump blocks to file, then read blocks from file and then iterate over blocks.
It is already done in reader/main.cpp.
But, as a bonus, you will get all statistics (optionally) which are used by the UI and you will not need to calculate it by your own.

There is also dumpBlocksToStream method in ProfilerManager which could be used instead of dumping blocks to file. But currently it is private. We can make it public or you can do it by your own if you do not want to wait.

[cas4ey]

But I must warn you that dumping and reading blocks are not very lightweight operations :)

[Jochen0x90h]

Thanks for the fast reply.

A profiler::dumpBlocksToStream wold be cool or even something like fillTreesFromFile in the profiler (profiler::fillTrees).

The print code in reader/main.cpp is commented out, is it possible to update it? Seems that the api has changed and I don't know how to determine which field of the union in BlocksTree is valid and how to iterate over children (which I don't need right now), but I can print the toplevel blocks.

[cas4ey]

@Jochen0x90h I'm sorry for huge delay

profiler::SerializedCSwitch* cs should be used when iterating over BlocksTreeRoot::sync.
profiler::SerializedBlock* node should be used when iterating over BlocksTreeRoot::children.
profiler::ArbitraryValue* value should be used if block type is BlockType::Value.
Block type could be retreived from profiler::BlockDescriptor which could be accessed via profiler::descriptors_list_t with node->id() as an index.
BlocksTreeRoot::events is a subset of BlocksTreeRoot::children containing only BlockType::Event and BlockType::Value blocks.

Yeah, this is not very friendly for external usage... it was designed for minimizing memory and performance impact for internal usage by profiler_gui (it does not pretend to design-of-the-year award anyway 😆 ).