guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#45893] [PATCH 0/2] DRAFT: Hint for options.


From: zimoun
Subject: [bug#45893] [PATCH 0/2] DRAFT: Hint for options.
Date: Tue, 26 Jan 2021 22:44:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi,

On Tue, 26 Jan 2021 at 22:00, Ludovic Courtès <ludo@gnu.org> wrote:

> As discussed on IRC, there’s (srfi srfi-41).

I am playing with it.  Thanks! :-)


>> (define (read-the-cache guess)
>>   (map (lambda (name)
>>          (identity name))
>>        (fold-available-packages
>>         (lambda* (name version result
>>                        #:key supported? deprecated?
>>                        #:allow-other-keys)
>>           (if (and supported? (not deprecated?))
>>               (cons name result)
>>               result))
>>         '())))
>
> Why ‘map’ here?  :-)

Good question!  Burn CPU? :-)


>> scheme@(guix-user)> ,time (define foo (read-the-cache "macs-mgit"))
>> ;; 3.492591s real time, 4.523108s run time.  1.530055s spent in GC.
>
> 3.5s?!  I have:
>
> scheme@(guix-user)> ,use(gnu packages)
> scheme@(guix-user)> ,time (define lst (fold-available-packages
>         (lambda* (name version result
>                        #:key supported? deprecated?
>                        #:allow-other-keys)
>           (if (and supported? (not deprecated?))
>               (cons name result)
>               result))
>         '()))
> ;;; <stdin>:2:6: warning: possibly unused local top-level variable `lst'
> ;; 0.093728s real time, 0.130037s run time.  0.065544s spent in GC.
>
> I assume you’re using ‘guix repl’ and the cache is authoritative,
> meaning that GUIX_PACKAGE_PATH is unset and there’s no ‘-L’ flag,
> right?

Yes.  GUIX_PACKAGE_PATH unset and no ’-L’ flag.  So, it should be worse
otherwise.  

Well, I am surprise by the timing difference.  I do not remember on
which machine I did: maybe an old desktop with spinning disks at work.


>> scheme@(guix-user)> ,profile (define foo (compute-distance "macs-mgit"))
>> %     cumulative   self             
>> time   seconds     seconds  procedure
>>  44.68     51.86      1.83  guix/memoization.scm:100:0
>>  17.55      0.72      0.72  hash-set!
>>  12.23      0.54      0.50  guix/utils.scm:863:2:mproc
>>   9.04      0.37      0.37  hash-ref
>
> OK, the naive memoizing implementation is inefficient, now we know.  :-)

’memoize’ or ’mlambda’?  Or both?  Well, the thread is mess up to I do
not remember which one had been used.

On the other hand, the naive recursive edit distance is well know to be
slow and ineffective.

Cheers,
simon





reply via email to

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