Re: Looking for a fast C++ parser

Scott Nicol <snicol@apk.net>
16 Aug 2005 11:16:33 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: Looking for a fast C++ parser vidar.hokstad@gmail.com (Vidar Hokstad) (2005-08-10)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-13)
Re: Looking for a fast C++ parser snicol@apk.net (Scott Nicol) (2005-08-16)
Re: Looking for a fast C++ parser Martin.Ward@durham.ac.uk (Martin Ward) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
Re: Looking for a fast C++ parser snicol@apk.net (Scott Nicol) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
| List of all articles for this month |

From: Scott Nicol <snicol@apk.net>
Newsgroups: comp.compilers
Date: 16 Aug 2005 11:16:33 -0400
Organization: Compilers Central
References: 05-06-133 05-08-030 05-08-035 05-08-051 <42FD7FC1.4040704@apk.net> <Pine.LNX.4.61.0508131127530.11001@tyr.diku.dk>
Keywords: C++, tools, performance

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


Post a followup to this message

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