Re: StringBuilder Extension: IsQuotedBy

Frans Bouma <[email protected]> Thu, 14 Feb 2008 12:28:29 +0100
Newsgroups gmane.comp.windows.devel.dotnet.clr
Message-ID <00b601c86efc$b962e820$2c28b860$@nl>
> perf, strings and loops
>
> I have developed a few .NET based parsers during the last few years and here
> are som fast comments:
>
> 1. avoid creating objects, all kinds of objects are "really expensive" to
> create, especially in loops. gc:s generally aren't an issue when parsing,
> unless parsing HUGE documents, a small parser will have completed before the
> gc kicks in.

        creating objects is indeed a bit expensive in .NET, though unavoidable
in some cases.

> 2. avoid virtual calls and delegates; both are great for flexibility but
slows
> your code down considerably when executed in tight parse-loops.

        I disagree. I did some testing with delegates and especially lambda
func objects and found out that calling a method through them 1 million times
costs about 17ms on .NET 3.5. Not something to worry about.

> 3. regexp really rocks if you are looking for flexibilty; in those cases
where
> flexibility is more important then speed regexp is really the perfect match,
> but if you are working on a small, well-defined and really fast parser don't
> even think about reg
> exp.

        Did you measure this? My regexp based parsers for UBB and our own DSL
as well as my LR(1) parser based on a regexp-using tokenizer disagrees with
you. Using compiled regexp's ofcourse (which is the default anyway in .net
2.0+ if I'm not mistaken, as regexp's are cached and compiled at first run).

        So unless you want to write your own NFA based tokenizer/scanner,
which is fun but also a lot of work, regexp's can greatly help and aren't
necessarily slower.

> (1), (2) and (3) all trade performance against readability and
> maintainability; I recomend regexp for all "slow" cases but if you really
are
> looking for performance it isn't a good solution. If a parse case is "slow"
or
> "fast" really depend on your development task, but be adviced, developing
complex parsers
> without regexp isn't for the faint-hearted =)

        It's described pretty well in a lot of books, so it's fairly
straightforward, though not doable in an hour or so.

        So, in short: did you measure performance and do you have some hard
numbers to show to prove your claims that regexp's are 'slow' ?

                FB

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com