C++ GenerateText incurs a lot of overhead for outputs larger as 1024 bytes

[bvgastel]

std::string is used as a accumulator for the output string in GenerateText(...) in idl_gen_text.cpp. Each time one byte is added, the entire string is copied in a new container. At least internally a better way of handling this is probably to use std::ostream &_text as argument for GenStruct (in idl_gen_text.cpp), and wrap in GenerateText the call to GenStruct with

std::stringstream stringaccumulator;
GenStruct(..., stringaccumulator);
_text = stringaccumulator.str();

Although text.reserve(1024); is a nice trick for micro benchmarks, this output method will incur unexpected large execution times for larger outputs.

Another benefit of using std::ostream as function signature is should be rather easy to change the output routine so accept calls like GenerateText(..., std::cout) (avoiding composing the entire buffer in memory).

+= does an append, which is similar in performance to appending to a std::vector, and the fastest way to do string concatenation as far as I know (certainly better than ostringstream).

Why would it be copying the entire string? It typically only reallocates every power of two in size.

[bvgastel]

Profiling a similar case showed a lot of overhead, but maybe it is 'just' the doubling of the buffer each time, instead of reallocing each time something is appended. Or I was confused about the exact meaning of +=.

But there is still an optimization opportunity here: is there any way to estimate a reasonable amount of bytes beforehand to minimize the number of realloc needed?

Also I would like to see the option to direct output it to std::cout.

FlatBuffers is a very performance-conscious libary. That said, I don't think these reallocs will cause performance problems, even when generating large amounts of JSON. You could probably estimate an ideal buffer size given the size of the input FlatBuffer you're generating from.. this is something I could add, but I don't think it will make much of a difference.

If you want to output to cout, first generating the whole string would still be faster than calling cout for every substring.

[bvgastel]

I agree. I was confused and too quick to judge. My apologies.

I still would like to see a streaming API to deal with large datasets on memory constrained systems (both reading and writing), maybe I will open a different ticket for it (as it not performance related).

You're right, it would be useful for that. Though I would hope that if you program for a memory constrained system, you don't use the text representation at all, and work with binary only.

[bvgastel]

I have one project that depends on an external JSON REST API, which sends over 1.5 Mb of decompressed JSON. The devices that should be supported are Android phones with 20 Mb of heap space available (so a continuous block of 1.5 Mb is almost impossible). Only because of the streaming APIs it is possible to even run on such devices. I can also imagine the use on constrained embedded systems like Arduino.