Re: byte-compiler very slow

[Colin Walters <walters@gnu.org>]

On Sun, 2002-07-21 at 16:15, Richard Stallman wrote:

> I think this is an extremely nice feature.  It is worth some slowdown,
> byt 5x or 9x seems a bit much.  It would be useful to do some
> profiling on this.  Does someeone want to do that?
> 
> I have a feeling Colin Walters, who added that feature, may be on
> vacation.  Colin, if you are there, could you please speak up?

Sorry, yes, semi-vacation; I've been trying to complete another free
software project.

> A simple optimization idea occurs to me.  The byte compiler could
> start processing a sexp in the old mode with the location tracking
> feature turned off.  If it encounters any sort of warning or error, it
> could abort processing of that sexp and restart with the location
> tracking feature turned on.  This would give the same results but
> all non-erroneous sexps would be processed faster.

That would be a good way to handle it, but unfortunately in the current
byte compiler implementation all sorts of side-effects happen while
processing a sexp.  It would be pretty tricky to unwind all of those.

I think for the short term, we could make batch-byte-compile set a flag
which reverts to the previous behavior of just printing line numbers. 
How does that sound?

> The only case where this causes a problem would be when macros do very
> weird things, such as if they their behavior depends on how many times
> the macro is expanded.  Perhaps it is an adequate solution to that
> problem to say "Don't do that".

There are already no guarantees on how many times a macro can be
expanded, or exactly when it will be expanded, so I don't see a problem
with this.