Menu
▾
▴
openvrml-develop
|
From: Damian M. <da...@er...> - 2001-12-28 11:50:38
|
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.
Some questions:
a) Could we come up some 'ctype' like scheme whereby we assume
that char is signed and we do a table lookup?
b) Alternatively, is a test such as
(isdigit(c) || ('A' <= c && c <= 'F') || ('a' <= c && c <= 'f'))
always valid for a hex digit.
While I fully appreciate that one should get it right before you make it
fast, we find that if something takes ages to load, be it a VRML file or
a web page, then users will complain.
Thanks - Damian (McGuckin)
Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468 | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer
|
|
From: Braden M. <br...@en...> - 2002-01-21 08:27:26
|
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.
> Some questions:
>
> a) Could we come up some 'ctype' like scheme whereby we assume
> that char is signed and we do a table lookup?
I imagine so.
> b) Alternatively, is a test such as
>
> (isdigit(c) || ('A' <= c && c <= 'F') || ('a' <= c && c <= 'f'))
>
> always valid for a hex digit.
Looks good to me.
> While I fully appreciate that one should get it right before you make it
> fast, we find that if something takes ages to load, be it a VRML file or
> a web page, then users will complain.
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.
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.
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Damian M. <da...@er...> - 2002-01-21 22:26:50
|
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. > 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. Thanks - Damian (McGuckin) Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064 Ph:+61-2-99063377 .. Fx:+61-2-99063468 | unsolicited email not wanted here ! Views and opinions here are mine and not those of any past or present employer |
|
From: Braden M. <br...@en...> - 2002-01-22 00:27:18
|
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...> |
Thanks for helping keep SourceForge clean.
X