From: David Kastrup <dak@gnu.org>
To: guile-user@gnu.org
Subject: Re: Lilypond speed (was Re: How to make GNU Guile more successful)
Date: Thu, 09 Mar 2017 00:50:58 +0100 [thread overview]
Message-ID: <87k27z49b1.fsf@fencepost.gnu.org> (raw)
In-Reply-To: CABsfGyV6aAGQGygbi4MD=tNT_FB1pDdLXsKGJXutM4L7Ca_R3A@mail.gmail.com
Thomas Morley <thomasmorley65@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
next prev parent reply other threads:[~2017-03-08 23:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 6:05 How to make GNU Guile more successful Michael Vehrs
2017-02-20 20:41 ` Arne Babenhauserheide
2017-02-21 6:01 ` Michael Vehrs
2017-02-21 17:18 ` Arne Babenhauserheide
2017-02-21 18:19 ` Amirouche
2017-02-21 18:31 ` Mike Gran
2017-02-21 18:33 ` Amirouche
2017-02-21 18:41 ` Mike Gran
2017-02-21 18:15 ` Amirouche
2017-02-21 19:25 ` Arne Babenhauserheide
2017-03-01 19:25 ` Amirouche
2017-03-03 5:28 ` Nala Ginrut
2017-03-03 9:18 ` David Kastrup
2017-03-03 11:30 ` Nala Ginrut
2017-03-03 12:19 ` David Kastrup
2017-03-03 13:35 ` Nala Ginrut
2017-03-04 23:44 ` Arne Babenhauserheide
2017-03-05 2:05 ` Thomas Morley
2017-03-05 14:01 ` Thomas Morley
2017-03-05 14:09 ` David Kastrup
2017-03-05 14:13 ` Thomas Morley
2017-03-05 14:27 ` Thomas Morley
2017-03-06 20:41 ` Lilypond speed (was Re: How to make GNU Guile more successful) Andy Wingo
2017-03-08 23:17 ` Thomas Morley
2017-03-08 23:50 ` David Kastrup [this message]
2017-03-09 6:48 ` Thien-Thi Nguyen
2017-03-09 12:13 ` Ludovic Courtès
2017-03-09 13:28 ` Paul
2017-03-10 16:18 ` Ludovic Courtès
2017-03-10 18:53 ` Paul
2017-03-12 21:07 ` Thomas Morley
2017-03-12 21:42 ` Ludovic Courtès
2017-03-12 23:20 ` Matt Wette
2017-03-13 12:52 ` Andy Wingo
2017-03-13 14:10 ` Controlling optimizations in 2.2 Ludovic Courtès
2017-03-13 21:26 ` Andy Wingo
2017-03-03 17:21 ` How to make GNU Guile more successful Matt Wette
2017-03-03 19:09 ` Amirouche
2017-03-03 19:16 ` Amirouche
2017-03-03 19:24 ` Mike Gran
2017-03-03 20:10 ` Matt Wette
2017-03-03 20:09 ` Matt Wette
2017-02-22 5:51 ` Michael Vehrs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k27z49b1.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).