Re: [openvrml-develop] Re: Vrml97Parser Performance

[Braden M. <br...@en...>]

On Mon, 2002-01-21 at 17:26, Damian McGuckin wrote:
> On 21 Jan 2002, Braden McDaniel wrote:
> 
> > On Fri, 2001-12-28 at 06:50, Damian McGuckin wrote:
> > >
> > > In our quest for speed, we inline'd _GetNextChar() and it turns out that
> > > on a 1000Mhz Pentium, isNewLineChar() is chewing up 10% of the time on
> > > nextToken().
> > >
> > > I was thinking of inlining all the routines in the anonymous namespace.
> >
> > Where inlining is showing a tangible performance increase, I certainly
> > think we should do it.
> 
> We certainly saw the gains under Windows and Linux.
> 
> > I'd like at some point to rewrite our parser to use Spirit instead of
> > ANTLR. I don't know if that'll end up giving us a speed boost, but I'd
> > be surprised if it hurt us. (My primary motivation is that I think
> > Spirit would be a less annoying dependency.) Spirit's still evolving
> > kinda rapidly, and the ANTLR parser works, so I'm not in a rush to get
> > this done.
> 
> I just had a look at Spirit. Looks cool.  Why would it be a less annoying
> dependency?  I must admit I have really only used Lex & Yacc in anger over
> the years.

Spirit grammars are C++ code, so there's no code generation step. You
just compile it--using the Spirit library--like any other C++ code.

> > It looks like you're focusing on the scanner here for performance
> > improvements; and I think any improvements there should help us
> > regardless of whether we're using ANTLR or Spirit.
> 
> The performance of the scanner increases the speed of loading the initial
> scene.  As this is the first thing somebody notices, then it sticks the
> hardest in their mind if it is slow.  I'd like to try and come up with a
> compiled form of the ASCII files.  You'd be amazed at how much time is
> spent reading integers and reals when you are loading a 6MB Ascii VRML
> file.

Ah, yes... The elusive "binary VRML format". :-)

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>