bug#3032: Major performance problem

[Alan Mackenzie]

Hi, Michael!

On Fri, Apr 17, 2009 at 02:31:16PM -0600, Michael Linck wrote:

> If you make a C++ header and try to define a long string, you can bring
> emacs to a grinding halt.  The scenario is as follows:  I need a test
> header to return the equivalent of some lengthy http resources for unit
> testing and I can't have file system interaction, so I have to hard
> code the scenarios in a variety of header files for the unit tests.
> For each resource, I need a string constant.  So I have to copy the
> body of the resource into the cxx header.

Could you perhaps describe this in more concrete terms, since I not quite
sure what you mean by an "http resource" - Maybe show me the top few
lines and the bottom few lines of what you're copying into the C
file.....

> Then backslash escape the quotes, then replace newlines with
> '\n"[newline]"' and then auto indent the buffer.  For a resource that
> is *merely* 8000 lines (that 8 thousand, not eight trillion) the simple
> quote escaping (replace '"' with '\"') takes more than 5-10 minutes,
> the newlines (no more than 1 per line) takes 5-10 minutes also.

....., and then please tell me exactly what keys you type to do this
replacement.

> This BUG however, is filed because the indentation has now been in
> progress for over 3 hours!  It was 37 percent complete an hour ago, now
> it's 40% complete.  That emacs instance is using up a entire CPU core,
> and the process of indenting a bit of code seems to be slowing down
> hard as it goes.  37% the first 2 hours, 3% the following hour.  I
> expect this *maybe* finish over the weekend.  I've been using emacs for
> at least 10 years, and this is shocking.

Yes, I agree.  Sorry!  I'm working on a bug at the moment which might
actually have the same root as the bug you've tripped over: it happens
when there's what I call a "brace dessert", a large section of text
without any '{'s or '}'s.  I'm reworking the relevant mechanism at the
moment, but it's quite a big job.

<OPTIONAL BIT, if you're interested in the Emacs internals>
CC Mode caches structural information about brace positions, and when the
changes are made to the source or even when the current position changes,
it updates this cache.  Sadly, at the moment, it scans backwards to the
previous brace position each time.  For typical code, this is fast
enough, but in a brace dessert, it scans back to the beginning of the
buffer each time, which is a performance disaster.
</OPTIONAL BIT>

> Another minor gripe is that I tried having emacs send this bug
> previously, but I had to decide to send it again manually, because it
> gives no indication of whether the bug e-mail was actually sent or not.

That bit's not my department, sorry.

> Anyway, in my professional opinion as a developer, it's time to put a
> stop to any "feature" updates for e-macs and hunker down with some
> optimizations. 

We do what we can.  :-)  But please keep on sending in bug reports
whenever you see a problem like this.  It's not like there is any general
optimisation that we need to get around to.  Rather, there are certain
"strange" types of source file, certain "strange" syntaxes which trigger
specific problems or show up bad assumptions that we've made in the past.

C is a horrendously complicated language in an editor.  C++ is an order
of magnitude worse, and in fact it has constructs which cannot be parsed
unambiguously without a full blown compiler.  So awkward "little" things
keep cropping up, things we haven't thought about, year after year.  We
knock them down, one by one.  ;-(

> emacs version 22.3.1

Any chance you could send me a CC Mode configuration dump, too?  Go to
that buffer and type C-c C-b.  Then cut and paste as appropriate into
your email.  And could you please try starting emacs as "emacs -Q", just
to make sure there's nothing in your init file causing the problem
(though I'm pretty sure there isn't).

As a temporary workaround, it might help to switch to a different mode
(M-x fundamental-mode) do the 8000 line edit, then switch back to C Mode
(M-x c-mode).

> Thanks, guys.

That's OK!  Thanks for taking the trouble to report the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).