Re: A mystery with slot access in LW

> On 27 Apr 2026, at 12:01, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote:
> 
> To produce the first report I ... have no idea what I did.  Sometimes it is fast, sometimes it is slow.  Sometimes recompiling & reloading makes it fast, sometimes it makes it slow.

This type of inconsistency might not be that complicated, it seems like you are only running 10^8 iterations, which is not enough to warm the CPU up with such a small code body. Try running a gc pass right before the benchmark, and optionally increase the number of iterations in the test to a billion, or so, if anything, it should reduce the variance between the tests significantly.

In the context of accessing individual slot values, the performance difference could be in whether the compiler manages to bake the slot offset into the access instructions, or looks it up at each invocation. While it appears that you have the name of the slot written verbatim in the accessor, as per

(slot-value a ‘i)

it may be that the runtime may be wary of the current and obsolete instances of the class A and trying to play safe. As you said, you had two versions of the class, with type declaration, and without it, so you had to recompile the class definition, which may have left obsolete instances behind that could make the runtime skittish. It does not seem like it should be a problem in your case, since you said that you start a fresh instance of LW for the test, but it could be something that can influence the performance noticeably, meaning, accessing slots by a hardwired offset, or calculating it on the fly.