Thomas Morley <thomasmorle...@gmail.com> 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
