Re: [PATCH] chainlint.pl: recognize test bodies defined via heredoc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux