Re: byte-compiler very slow

[Richard Stallman]

    A first quick comparison between the 21.2.1 and latest CVS versions of
    bytecomp.el codes showed me that the main addition that could impact
    performance could be related to the new (nice) feature that reports
    symbol positions on byte-compiler messages.

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?

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.

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".