GNU bug report logs - #76505
31.0.50; igc: M-x project-compile is slow

Previous Next

Full log

View this message in rfc822 format

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Ihor Radchenko <yantar92 <at> posteo.net>, 76505 <at> debbugs.gnu.org
Subject: bug#76505: 31.0.50; igc: M-x project-compile is slow
Date: Sun, 23 Feb 2025 21:36:32 +0100

On Sun, Feb 23 2025, Pip Cet wrote:
> The problem, I think, is that the do { ... } while () loop runs (at
> least) twice: the first time, a busy trace finishes, the code falls
> through, "now" is reset to the *current* clock, which makes
> (availableEnd - now) "negative".  But as the types are both unsigned,
> the "negative" value will correspond to a large Clock value, which will
> make MPS reach the conclusion it's a good time to start a full
> collection.
>
>
> I think the intention was for "multiplier" in the above code always to
> be at least 1.0.

Good catch! The wrapping on overflow looks problematic.

> The documentation isn't quite clear on what
> "multiplier" is supposed to be set to, particularly in our case where we
> want to discourage full collections.  1.0 seems to be the lowest safe
> value, so let's use that?

Does MPS make a distinction between full collection and "normal"
collections?  Are those somehow non-incremental?

It could be that MPS decides to start a full trace, but it advances the
trace only while (now < intervalEnd).

If "full collections" are just like normnal collections, then I see no
particular reason why starting full traces should be discouraged.

(My guess is that the slowness has something to do with intervals, but I
have zero evidence for that.)

Helmut

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.