Subject: [bug#50384] [PATCH v2] Optimise search-patch (reducing I/O)

From: zimoun <[email-masked]>
Date: Mon, 06 Sep 2021 10:39:40 +0200

Hi Maxime,

Thanks for looking at optimising stuff. :-)

On Sun, 05 Sep 2021 at 21:48, Maxime Devos <[email-masked]> wrote:

> Let's compare the numbers again!  This time, I've run
>
> echo powersave |sudo tee /sys/devices/system/cpu/cpufreq/policy{0,1,2,3}/scaling_governor
>
> to make sure the CPU frequency doesn't change.  On a hot (disk) cache:
>
> # After the patch series
> time GUIX_PROFILING="rpc gc" ./the-optimised-guix/bin/guix build -d --no-grafts pigx

[...]

> So on a hot disk cache, there doesn't appear to be any improvement
> (except for ‘time spent in GC’ -- presumably that's due to the optimisations
> to guix/base32.scm).

Which kind of disk do you have?  SSD, spinning HDD, other?

> What about a cold cache?
>
> # After the patch series
>
> sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
> ./the-optimised-guix/bin/guix --help
> time GUIX_PROFILING="rpc gc" ./the-optimised-guix/bin/guix build -d --no-grafts pigx
> /gnu/store/fq6x8d2vcm6sbjkimg7g8kcgb4c5xv1b-pigx-0.0.3.drv
> Remote procedure call summary: 5949 RPCs
>   built-in-builders              ...     1
>   add-to-store                   ...     3
>   add-to-store/tree              ...    26
>   add-temp-root                  ...   195
>   valid-path?                    ...   195
>   add-text-to-store              ...  5529
> Garbage collection statistics:
>   heap size:        93.85 MiB
>   allocated:        312.03 MiB
>   GC times:         17
>   time spent in GC: 3.37 seconds (23% of user time)
>
> real	1m39,178s
> user	0m14,557s
> sys	0m0,990s

How the average (against 3 examples) looks like?

> It seems that if the disk cache is cold, the time-to-derivation decreases
> a little by this patch series.  Much less than I had hoped for though; I'll
> have to look into other areas for interesting performance gains ...

Please update the number using your diff showed in [1]. :-)

1: <http://issues.guix.gnu.org/50384#4>

All the best,
simon