Re: Compilation time with Guile 3.0.3-to-be

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

Andy Wingo <wingo@igalia.com> skribis:

> On Thu 04 Jun 2020 09:50, Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> For the record, the optimizations currently used in (guix build compile)
>> are between the new -O0 and -O1:
>>
>>   (cond ((or (string-contains file "gnu/packages/")
>>              (string-contains file "gnu/tests/"))
>>          ;; Level 0 is good enough but partial evaluation helps preserve the
>>          ;; "macro writer's bill of rights".
>>          (override-option #:partial-eval? #t
>>                           (optimizations-for-level 0)))
>
> Here fwiw I would use -O1.  It is basically the same as -O0 except that
> it adds partial evaluation and it inlines primcalls.  If you are willing
> to do partial evaluation, you are probably willing to inline primcalls
> too; I think it typically leads to less code and the compilation time is
> similar to -O0.

Alright, let’s do that.

>>         ((string-contains file "gnu/services/")
>>          ;; '-O2 -Ono-letrectify' compiles about ~20% faster than '-O2' for
>>          ;; large files like gnu/services/mail.scm.
>>          (override-option #:letrectify? #f
>>                           (optimizations-for-level 2)))
>
> Interesting.  I think this is probably a bug of some sort that we'll
> have to keep working on.

Yeah I think memory consumption increases noticeably with
letrectification, which in turns means more GC activity.

> Note that in 3.0.3 there is also a new phase called "lowering".  Before
> a compiler from Tree-IL to language X is called, the tree-IL program is
> "lowered" -- meaning canonicalized and optionally optimized.
>
> (define (lower-exp exp env optimization-level opts)
>   (let ((make-lowerer (language-lowerer (lookup-language 'tree-il))))
>     ((make-lowerer optimization-level opts) exp env)))
>
> Similarly there is an analysis pass for warnings, which runs before
> lowering:
>
> (define (analyze-exp exp env warning-level warnings)
>   (let ((make-analyzer (language-analyzer (lookup-language 'tree-il))))
>     ((make-analyzer warning-level warnings) exp env)))
>
> These can be interesting to test different phases of the tree-il ->
> bytecode path.

OK, I’ll take a look.

>> The profile looks like this:
>>
>> scheme@(guile-user)> ,pr (define t (call-with-input-file  "gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 'tree-il))))
>> %     cumulative   self             
>> time   seconds     seconds  procedure
>>  13.16      0.45      0.40  anon #x1136458

[...]

>> It’d be great to waive the anonymity of that first lambda.  :-)
>
> I think I just fixed it :)

Yay, thank you, it’s much nicer now!

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(system base compile)
scheme@(guile-user)> ,pr (define t (call-with-input-file  "gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to 'tree-il))))
%     cumulative   self             
time   seconds     seconds  procedure
 16.24      0.52      0.49  set-source-properties!
 12.82      0.47      0.39  ice-9/boot-9.scm:3128:0:module-gensym
  4.27      0.13      0.13  ice-9/popen.scm:168:0:reap-pipes
  4.27      0.13      0.13  ice-9/psyntax.scm:749:8:search
  3.42      0.13      0.10  ice-9/boot-9.scm:2201:0:%load-announce
  3.42      0.10      0.10  ice-9/boot-9.scm:3434:11:b
  3.42      0.10      0.10  read
  3.42      0.10      0.10  source-properties
  2.56     50.34      0.08  ice-9/threads.scm:388:4
  2.56     12.56      0.08  ice-9/psyntax.scm:1611:10:parse
  2.56      0.08      0.08  module-variable
  2.56      0.08      0.08  memoize-expression
  2.56      0.08      0.08  ice-9/psyntax.scm:668:4:make-binding-wrap
  1.71      0.08      0.05  ice-9/boot-9.scm:2790:0:module-ref-submodule
  1.71      0.05      0.05  number->string
  1.71      0.05      0.05  ice-9/boot-9.scm:1396:0:symbol-append
  1.71      0.05      0.05  append
  1.71      0.05      0.05  string-append
  0.85    270.25      0.03  ice-9/boot-9.scm:220:5:map1
--8<---------------cut here---------------end--------------->8---

Nowadays I freak out every time I see those weak hash tables show up.  ;-)
Well, given the size of the file, it’s no surprise that
‘set-source-properties!’ is called a lot, but it’s still worrying that
it’s #1.  (Perhaps an issue similar to <https://bugs.gnu.org/40194>?)

> I think the reap-pipes call is a pretty bad sign, incidentally!

Yeah, it was discussed recently and I can’t explain it:

  https://lists.gnu.org/archive/html/guile-devel/2020-05/msg00019.html

Thanks for your feedback!

Ludo’.