performance about istream_input's in_maximum argument

[shuizaiku7]

Hi, i'm tring to handle very big files.
The item i wanna discard may not be known.
But it's safe to give a value that is 1/1000 of the whole file size.
Is it ok to give a big value for in_maximum?

Let's say, if 1024 and 102400 are safe, will 102400 do harm to the runtime?

[ColinH]

Assuming you are unable to use the mmap-based file input, which would be the preferred way to parse large files (and would sidestep the question of the in_maximum parameter) ... for which there isn't a clear answer regarding performance.

If you need a 100KB maximum buffer size because some actions need to access that large a portion of the input then that should work just fine. If however you need a 100KB buffer because your grammar back-tracks or does a look-ahead across that much of the input then you might have a performance problem. How big of a problem depends on the details of your grammar (and input), and the same problem would presumably occur with e memory_input or file_input, too, albeit to a slightly lesser degree. In this case I would try to optimise the grammar.

Have you already implemented your grammar? If yes, have you tried large values for in_maximum? For a modern computer 100KB in itself is not exactly a lot.

[shuizaiku7]

Thanks for your reminding.
After learning about the cocept of mmp, i find that file_input will address my problem.

And by the way, if will not use the position info in my business logic.
Is it more efficient to use tracking_mode::lazy?

[ColinH]

Yes, if you never use the position, or use it very rarely like only in parse error exceptions that abort the parsing run, then lazy is better.