Re: Looking for a fast C++ parser

Peter "Firefly" Lund wrote:
> Not just a few MHz, I am afraid. It makes loading of new files a lot
> slower and screen update sluggish. I also want the screen to react in
> 100ms or less when I type (I have very fast reflexes) otherwise it feels
> "wrong". Deleting or inserting '/*' should not result in noticeable
> delays (vim) or miscolouring (Emacs).


Interesting, I've never noticed sluggish response with vim, and most
of my computers can be described as anything but quick. I tried a
simple test on a 733MHz Celeron with 512MB RAM running an
couple-year-old version of Linux. I messed with a C source file that
is around 5000 lines and 130k by adding/removing a "/*" which changes
coloring on about 100 lines. I tried it at both near the top and near
the bottom of the file.


Doing this 4 times a second (i.e. 2 remove/add cycles) shows a load of
around 5% (using top). Given that there is some overhead just from
X-windows redrawing the text window (80x62), it appears the CPU load
from vim coloring is minimal. Just forcing a redraw with no coloring
changes (ctrl-L) produces similar load.


Memory usage (above vim with no file loaded) is around 500k, or 3x the
file size. Since you've got to load the file anyway (unless you want to
buffer from disc), you can assume extra memory usage due to coloring is
no more than 2x file size.


If I was running a 4.77MHz 8088 with 256k RAM, I'd have something to
worry about.
--
Scott Nicol
snicol@apk.net

Return to the comp.compilers page.
Search the comp.compilers archives again.