`string` can cause parsing to be slow with `verbose_error`

[m4rw3r]

Problem

string allocates a copy of the string it was trying to match on error in verbose_error mode. This can cause really bad performance when eg. trying to match multiple different tags using nested or-combinators (used in the mp4-benchmark from nom_benchmarks).

[m4rw3r]

The string parser could be made to just return the Error::Expected on the differing character. This might even allow for removal of the verbose_error feature completely since Error will not contain any heap-allocated data.

This will result in slightly less useful error messages from the string parser, since it will not display the full string. In addition to this the error position returned from the string parser would be set to the unexpected character instead of the start of the match (the current behaviour). This could break some buffer-usage where it is expected to restart the parsing from the start of the attempted string match instead of restarting from the offending character.

[m4rw3r]

The string parser could be made to just return the Error::Expected on the differing character. This might even allow for removal of the verbose_error feature completely since Error will not contain any heap-allocated data.

This will result in slightly less useful error messages from the string parser, since it will not display the full string. In addition to this the error position returned from the string parser would be set to the unexpected character instead of the start of the match (the current behaviour). This could break some buffer-usage where it is expected to restart the parsing from the start of the attempted string match instead of restarting from the offending character.

[m4rw3r]

Another possibility is to only allow 'static lifetime on the string to match against, but this will probably be too limiting.

Combining #23 with just reporting the offending character (ie. you get a full back-trace pointing to the string parser) will most likely solve the issue where you actually need to see which string it is trying to match.

[m4rw3r]

Another possibility is to only allow 'static lifetime on the string to match against, but this will probably be too limiting.

Combining #23 with just reporting the offending character (ie. you get a full back-trace pointing to the string parser) will most likely solve the issue where you actually need to see which string it is trying to match.