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

[David Kastrup]

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/paper-outputter.cc with

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

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

    SCM
    Paper_outputter::module () const
    {
      return output_module_;
    }

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

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

    void
    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)
  (ly:format
   "~a ~4f ~4f draw_circle"
   (if fill
       "true"
       "false")
   radius thick))

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

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
> https://www.gnu.org/software/guile/download/
> 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