guix-patches
[Top][All Lists]
Advanced

[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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]