Re: [libgpiod][PATCH 1/1] gpio-tools-test.bats: modify delays in toggle test

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Thu, Jun 1, 2023 at 3:16 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Wed, May 31, 2023 at 3:17 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Tue, May 30, 2023 at 06:07:52PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, May 30, 2023 at 5:18 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > > > On Tue, May 30, 2023 at 04:52:36PM +0200, Bartosz Golaszewski wrote:
> > > > > On Tue, May 30, 2023 at 4:24 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > > >
> > > > > > On Tue, May 30, 2023 at 04:13:06PM +0200, Bartosz Golaszewski wrote:
> > > > > > > On Tue, May 30, 2023 at 12:05 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > >
> > > > > I went with bats because it looked the fastest to write tests in -
> > > > > it's shell after all.
> > > > >
> > > >
> > > > Really?  I wouldn't write anything of consequence in shell if Python was
> > > > an option.
> > > >
> > > > How about Rust?  I've gotten over how spartan the Rust test framework is
> > > > so I wouldn't have a problem writing it in that either.
> > > >
> > >
> > > I have a very strong preference for Python. I am quite bad at Rust.
> > > Whatever is in bindings/rust/ is Viresh' jurisdiction and I defer to
> > > him but I would prefer to be able to keep track of what's happening in
> > > tools/ and work on it myself without too much frustration. And writing
> > > anything in rust has been pure frustration so far.
> > >
> >
> > Fair enough, Python it is then.
> >
> > I personally had no problem picking up Rust - seems Rust and I have a
> > similar view - I've always had issues with the vagueness of ownership
> > and lifetimes in other languages, particularly C/C++.  Rust gets it.
> > And if you do make a hash of something clippy provides good suggestions,
> > or at least clearly identifies the problem. That helped me a lot with
> > the learning curve.
> >
> > Cheers,
> > Kent.
>
> Before jumping into a complete rewrite, I thought it's worth at least
> giving bats a chance and see if we can simply fix the delay. A quick
> strace run is telling me this:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ------------------
>  91,93   20,569295        1014     20284      8653 wait4
>   1,72    0,384721           0    814827           rt_sigprocmask
>   1,35    0,301451           1    171558    142755 readlink
>   1,19    0,265404           1    261357         8 read
>   1,04    0,233103          20     11283           clone
>   0,50    0,110845          16      6848      1025 execve
>   0,49    0,110042           0    128382     13692 newfstatat
>   0,33    0,073843           0     95369     49559 ioctl
>   0,25    0,055440           0     78664           mmap
>   0,20    0,044861           2     22081           write
> [...]
>
> It suggests, there's some issue with waiting for exiting processes
> that if we fix, we should decrease the test time by at least 90%.
>
> Bart

Nevermind that, turns out strace -c -f doesn't do what I thought it
does. It only shows the stats for the top process which mostly just
waits for other processes. That's not the culprit. I need to figure
out a way to correctly profile this.

Bart