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

Bartosz Golaszewski
2023-06-01T14:54:13Z

On Thu, Jun 1, 2023 at 3:16 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Wed, May 31, 2023 at 3:17 AM Kent Gibson <warthog618@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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