[Top][All Lists]

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

Re: Lilypond speed (was Re: How to make GNU Guile more successful)

From: David Kastrup
Subject: Re: Lilypond speed (was Re: How to make GNU Guile more successful)
Date: Thu, 09 Mar 2017 00:50:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> So guile 2.1.7 is indeed faster than 2.0.14 with this test-file, otoh
> I've redone testings with the other file and can confirm 2.1.7 being
> slower there.
> Currently I've no clue why.

Lot's of output?  The output files are generated in
lily/ with

    Paper_outputter::dump_string (SCM scm)
      return scm_display (scm, file ());

    Paper_outputter::scheme_to_string (SCM scm)
      return scm_eval (scm, output_module_);

    Paper_outputter::module () const
      return output_module_;

    Paper_outputter::output_scheme (SCM scm)
      SCM str = scheme_to_string (scm);
      if (scm_is_string (str))
        dump_string (str);
      return str;

    paper_outputter_dump (void *po, SCM x)
      Paper_outputter *me = (Paper_outputter *) po;
      return me->output_scheme (x);

    Paper_outputter::output_stencil (Stencil stil)
      interpret_stencil_expression (stil.expr (), paper_outputter_dump,
                                    (void *) this, Offset (0, 0));

So every output item is generated by running a humongous expression
through scm_eval and then calling scm_display on the expression (when it
turns out it is a string).

For PDF output, those strings are generated in the PostScript backend in
scm/output-ps.scm, typically with stuff like:

(define (char font i)
  (ly:format "~a (\\~a) show"
             (ps-font-command font)
             (ly:inexact->string i 8)))

(define (circle radius thick fill)
   "~a ~4f ~4f draw_circle"
   (if fill
   radius thick))

with ly:format defined in C and consequently ping-ponging strings
through the SCM API (using scm_to_locale_stringbuf and

So the basic question is whether the output generation phase (after all
typesetting and page breaking has finished) is significantly involved in
the total slowdown or not.

> Btw, I've improved my local setup to be able to test lilypond more
> quickly with different guile versions. Though I wasn't able to compile
> 1.8.8, neither from the repository nor from the tarball downloaded
> from
> Due to:
> async.c: In function 'scm_i_queue_async_cell':
> async.c:243:14: error: variable 'count' set but not used
> [-Werror=unused-but-set-variable]
>        size_t count;
>               ^
> Am I missing something?

Remove compilation option -Wall here?

> I'm aware noone is interested in developing 1.8.8 further,

There was just a question on the developer list (I think) how to best
maintain a fork of 1.8.

David Kastrup

reply via email to

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