lilypond-devel
[Top][All Lists]
Advanced

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

Re: Grow heap aggressively during music interpretation (issue 561390043


From: David Kastrup
Subject: Re: Grow heap aggressively during music interpretation (issue 561390043 by address@hidden)
Date: Fri, 07 Feb 2020 19:27:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> Single threaded, the numbers make more sense:
>
>
> MAX=INIT=2G
> gc time taken: 1.843968805
> User time (seconds): 49.36
>
> MAX=INIT=1G
> gc time taken: 3.291264925
> User time (seconds): 51.74
>
> MAX=INIT=800M
> gc time taken: 5.760042906
> User time (seconds): 54.62
>
> 500M
> gc time taken: 17.921457247
> User time (seconds): 68.24
>
>
> It's interesting to note that the multithreaded collector doesn't really
> help.

I think that this may be due to both/either our use of mark hooks and of
finalisers for calling destructors.  Either may cause serialisation.
Another serialisation is because Guile itself switches BGC to Java mode
where finalised objects can no longer be marked (or something like that:
the exact semantics I do not remember).  And of course the C++ free
store still has to do its full job.

That's one reason why I think it may be a good idea to "punt" a bit on
the encoding stuff by keeping it basically in 8-bit domain: it may give
us an operative LilyPond for experimenting with other Guilev2 aspects,
like making a custom allocator for Scheme-containing data structures
instead of being in a state where only parts are operative.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".



reply via email to

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