[Perf] Use heuristics to avoid allocations in Sanitizer::str_till_eol

[vicsn]

Motivation

Replaces #2517

Original PR message:

(transferred from ProvableHQ#6, and asking @d0cd for a review as suggested there)

The Sanitizer is used very prominently in our parsing functions, and it is also a source of many allocations, most of which are temporary and avoidable.

The potential perf improvements are quite large, and I've measured them both with a 15-minute run of a --dev node and using hyperfine on a small binary that parsed all the valid .aleo programs currently present in the snarkVM codebase.

dev node:

all allocs are down ~15%, of which almost all are temporary
in Program::from_str specifically, allocs are reduced by ~64%, of which temp allocs ~88%

parsing all .aleo programs using Program::from_str:

allocs are reduced by ~41%
growth reallocs are down ~70%
runtime is reduced by ~31%

Test Plan

CI run link

[d0cd]

Overall, I'm in favor of this PR. It would be helpful to add test cases for the this specific parser, especially for when the heuristic is and isn't taken.

[d0cd]

Does this need to use a till operator until Self::eol since this is knows to be a single line string?

[ljedrz]

good point; I'm not sure, but since I'm not super savvy with nom, I preferred to leave it intact

[d0cd]

Nit. Can you explain the heuristic in the comment?

[ljedrz]

added to my TODO (as with the Program-related comment, I'd suggest to add it separately to avoid merge-related issues)

[d0cd]

Is the goal to avoid allocations in this method?

[ljedrz]

IIRC the allocations that are avoided are primarily:

• the ones from verify
• the ones from recognize
• the ones from value
• but most importantly, the alt-related ones from here and here

[zkxuerb]

LGTM

[ljedrz]

@vicsn I updated the original branch with 2 commits addressing the notes on extra docs and the redundant use of eol. Feel free to cherry-pick those, they should apply cleanly.

@d0cd as for extra tests, note that str_till_eol is only ever used in parse_comment, and there are already several applicable test cases for it, including ones that would utilize the faster approach. Do you feel like those are missing any variants?

[d0cd]

@ljedrz on initial scan, I don't see test case for a multi-line comment, multiple single line comments, multiple multi-line comments, and interleavings of the two. I'll leave it to your discretion, but I would at least recommend a multi-line comment and multiple single line comments.

I also saw that you use eoi in the update. Looks good to me, but I would also recommend explaining in a comment that this is valid because before is a single line string.

The reason I am being so insistent on comments is that these parsers are quite sensitive and not many people have a deep expertise in nom.

[ljedrz]

@vics I addressed the comments in 2 new commits:

• 3dd61c2
• 39ab91f

[ljedrz]

While not a big deal (extra test cases, docs, and one optimization), this PR was still missing the 4 extra commits mentioned at the end. I can include them in a follow-up shortly.

[vicsn]

@ljedrz apologies I overlooked that I had to update my branch