On Mon, Jul 08, 2024 at 04:06:47PM -0400, Eric Sunshine wrote: > One thing we may want to measure is how much extra time we're wasting > for the (very) common case of latching heredoc bodies only to then > ignore them. In particular, we may want to add a flag to ShellParser > telling it whether or not to latch heredoc bodies, and enable that > flag in subclass ScriptParser, but leave it disabled in subclass > TestParser since only ScriptParser currently cares about the heredoc > body. I doubt it's much to hold on to a few extra small buffers. But it should be easy to measure. Here are hyperfine results for checking all of our test scripts both before (old.pl) and after (new.pl) your chainlint.pl, with threading disabled: Benchmark 1: perl old.pl t[0-9]*.sh Time (mean ± σ): 4.215 s ± 0.052 s [User: 4.187 s, System: 0.028 s] Range (min … max): 4.124 s … 4.288 s 10 runs Benchmark 2: perl new.pl t[0-9]*.sh Time (mean ± σ): 4.295 s ± 0.060 s [User: 4.264 s, System: 0.031 s] Range (min … max): 4.229 s … 4.419 s 10 runs Summary perl old.pl t[0-9]*.sh ran 1.02 ± 0.02 times faster than perl new.pl t[0-9]*.sh So it does seem to make a small difference, but we're within the noise. > In the long run, I think we probably want to build a full parse tree, > attach relevant information (such as a heredoc body) to each node, and > then walk the tree, rather than trying to perform on-the-fly lints and > other operations on the token stream as is currently the case. > [...] Yeah, all of that sounds very sensible long term, but probably not worth worrying about for this topic. -Peff