On 10/9/14, 7:09 AM, Dicebot wrote:
Yes and this is exactly why I am that concerned about recent memory
management policy thread. Don has already stated it in his talks but I
will repeat important points:
1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating garbage in a
form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically lot of
temporarily garbage allocations
What would be a few good examples of (3)? Thanks.
This is a very simple issue that will prevent us from using and
contributing to majority of Phobos even when D2 port is finished.
Switch to input/output ranges as API fundamentals was supposed to fix
it.
Unfortunately it doesn't. RC does. Lazy computation relies on escaping
ranges all over the place (i.e. as fields inside structs implementing
the lazy computation). If there's no way to track those many tidbits,
resources cannot be reclaimed timely.
Walter and I have only recently achieved clarity on this.
Custom management policies as you propose won't fix it at all
because garbage will still be there, simply managed in a different way.
I'm not sure I understand this.
This is especially dissapointing because it was a first time when
declared big effort seemed to help our needs but it got abandoned after
very first attempts.
It hasn't gotten abandoned; it's on the back burner. Lazification is a
good thing to do, but won't get us closer to taking the garbage out.
Andrei
