[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#45948] [PATCH 0/5] Improvements to the Automake SRFI 64 test driver
From: |
Ludovic Courtès |
Subject: |
[bug#45948] [PATCH 0/5] Improvements to the Automake SRFI 64 test driver. |
Date: |
Mon, 01 Feb 2021 23:18:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hello!
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>> I never felt the need for this since most individual files run quickly
>> enough (and those that don’t should be optimized…), but it can be
>> useful.
>
> What triggered it for me was trying to iterate using tests added to the
> tests/packages.scm test module:
[...]
> 1.6 s; better than 46 s!
Quite a difference, indeed!
Some tests, like ‘tests/store.scm’, invoke the GC (via ‘delete-paths’
calls in particular), and this is a bad idea because it takes ages.
What I meant by “should be optimized” is that these tests should be
tweaked to avoid invoking the GC as much as possible.
That’s not the case of ‘tests/packages.scm’ though. Which gives me an
idea: what would it take to modify the test driver so it can print the
time spent in each test? :-)
That would probably prove helpful to optimize core Guix.
In many cases, I also run the one test I’m interested in through Geiser,
which gives an optimally fast feedback loop.
> We can also check the time the suspected slow test took:
>
> $ time make check TESTS=tests/packages.scm
> SCM_LOG_DRIVER_FLAGS="--select='fold-available-packages with/without cache'"
> [...]
> PASS: tests/packages.scm - fold-available-packages with/without cache
Ah ha! Turns out a large part of the time was due to the O(n²) behavior
of the various list operations (the list of packages is big enough!).
Fixed in 73744725dd0a65cddaa9251f104f17ca27756479.
>>> +The underlying SRFI 64 custom Automake test driver used for the 'check'
>>> +test suite (located at @file{build-aux/test-driver.scm}) also allows
>>
>> Maybe shorten to “The underlying test driver (located at
>> @file{build-aux/test-driver.scm}) also allows”.
>
> I see value in explicitly stating what it is, as it took me some effort
> to be able to answer that question when I started looking at it (the
> test driver).
Agreed. It just seemed to me that we were mentioning three new
concepts/tools in passing: SRFI-64, Automake, and test drivers.
> I've now pushed this series to master; thank you for the review!
Thank you!
Ludo’.
- [bug#45948] [PATCH 0/5] Improvements to the Automake SRFI 64 test driver.,
Ludovic Courtès <=