Re: [Sbcl-devel] [Sbcl-commits] CVS: sbcl NEWS, 1.1849, 1.1850 version.lisp-expr, 1.5110, 1.5111

[Nikodemus S. <nik...@ra...>]

On 16 November 2010 18:01, Martin Cracauer <cra...@co...> wrote:

> I'll give it one more try but at some point I'd like to open
> negotiations about backing out your change.  The increase in compile
> time is so large that debugging it turns into a nasty time sink.
> :max-samples expands on it's own, so I'll try max-depth.

The sample-vector expands on it's own, but it new samples aren't
recorded after samples-trace-count > samples-max-samples. At least
should not.

Just to check: did you try with :CLASSIC using the
concatenate-inst.lisp? I assume that didn't blow up. If it did, then
something very funky is going on. I would be deeply surprised if it's
the *CONCATENATE-OPEN-CODE-LIMIT* that's responsible instead of the
AREF-with-offset/INCF change.

Assuming it is the AREF-with-offset/INCF change, and we cannot
identify the source of the slowdown you're seeing, I can back out the
change. While it gives a small improvement in all my test-cases for
both compile-time and performance, I don't consider it critical.
Unsurprisingly I would really like to identify the underlying issue,
though, since it may well help sorting out some other compiler
performance issues as well -- or at least help us understand them.

If it is the *CONCATENATE-OPEN-CODE-LIMIT* that is guilty... I'd
_really_ like to identify the issue, because adding that is necessary
for simple-but-realistic cases to compile without nonlinear explosion
in compile-time as length of string-constants increases.

Cheers,

 -- Nikodemus