The difference between parsing using a string or a stream (Poco c++)

Question

I have written a simple hierarchical json-parser, using POCO JSON, to be used as a sax parser. Is their any difference in the result if i use a string or a stream as input to the parse method, see call below, or are the different constructors equivalent?

Parser parser;
DefaultHandler handler;
parser.setHandler(&handler);
parser.parse(input);

In terms of memory consumption, speed etc?

Humpbacked

Answer 1

std::string version is just a wrapper that creates stream on your behalf, so at the end the total will be roughly the same, string is just more convenient for user.

[EDIT]

This was changed for 1.5.2 - wrapping was removed so that now both (stream and string) versions iterate. The Benchmark Example can be used to determine how much is stream slower than string.

[/EDIT]

Please note that there are some breaking changes coming in 1.5.2 - DefaultHandler name was removed and internally handler has been turned into auto-created smart pointer (that's the main reason we had to obsolete DefaultHandler so existing code would not pass stack-created handler to the smart pointer, it was not a good design to start with). So, in 1.5.2, explicit handler creation will not be needed anymore for default parsing:

std::string json = "{ \"test\" : null }";
Parser parser;
Var result = parser.parse(json);

If you are concerned with performance, note also that Poco::JSON parser speed, as it stands now, is poor and we will be using either the very fast parser from Poco::Web::JSON or something faster (if we can find/write it). Bottom line, 1.5.x is still W.I.P.

Hope this helps.

EDIT:

Benchmarks on Windows and Mac (~15MB JSON file):

Windows

Poco::JSON: 1 195 313 [us]
Poco::Web::JSON: 403 320 [us]
json-parser: 321 289 [us]
libjson: 610 352 [us]

MAC (clang)

Poco::JSON: 480 965 [us]
Poco::Web::JSON: 176 297 [us]
json-parser: 220 172 [us]

Avoidance

And it has the characteristics of a SAX-parser? – Humpbacked

In 1.5.2, the default handler (ParseHandler) behaves more DOM-like (i.e. retains the whole tree in memory); end-user can easily provide a handler with SAX-like behavior. – Avoidance