On Tue, 2008-08-26 at 12:00 -0400, Braden McDaniel wrote:
> On Tue, 2008-08-26 at 11:06 +0200, Johannes Brand wrote:
> > I tested the OpenVRML Parser for VRML97 files and it worked well, so
> > far. Unfortunately it takes quite a long time to parse/load VRML files
> > of sizes around 1 or 2Mb. Is it normal to have parsing times around 1
> > Minute for file sizes of 2.3 MB when just using the
> > "openvrml::null_vrml97_parse_actions" and the standard "parse" function
> > of "pretty_print.cpp" ??
>
> The parser does a good deal of semantic checking, so it's probably never
> going to be the fastest parsing solution possible. However, these times
> do sound excessive. Profiling the parse using input like you have
> available would be a very useful activity. Depending on where the
> problems lie, it may be possible to make some significant improvements.
For the benefit of anyone reading this and thinking, "Oh, God,
OpenVRML's parser must be a complete dog," let me provide a bit of an
epilog to this.
Frank was kind enough to share a 2.3 MB file for me to test. Running
tests/parse-vrml97 on this file executes in under 2 seconds on my
Opteron 285 box. Note that this execution time includes start-up costs
(which are nontrivial on the trunk openvrml I tested; libopenvrml now
opens and reads several small XML files as part of initialization) and
the time taken to emit several warnings to stderr. For this test, I
built openvrml using the configure-gcc-opt wrapper script in svn.
So while OpenVRML's parser is never going to be the fastest-possible
parser due to the design constraints I mention above, it seems to be no
slouch either. Regarding Frank's initial results, I think the moral of
the story is: use optimized builds when testing performance. :-)
(Sorry, Frank... But I needed to defend OpenVRML here. ;-)
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
