I'm working on a fairly complicated model that contains both mesh2 and povray
primitives.  Because of the complexity of the objects, some of the included
scene files are pretty large, around 5 Mb.  Reading and experimentation has
shown that placing macros throughout those files can take a performance hit
when the macro gets called from another file, so I've begun inlining them when
possible.

What are other things that can be done to reduce parse times (aside from
reducing file sizes)?

I know in the past there was talk about a preparsed, binary format.  Has anyone
been doing anything with that lately?

-Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> I'm working on a fairly complicated model that contains both mesh2 and povray
> primitives.  Because of the complexity of the objects, some of the included
> scene files are pretty large, around 5 Mb.  Reading and experimentation has
> shown that placing macros throughout those files can take a performance hit
> when the macro gets called from another file, so I've begun inlining them when
> possible.

That's to be expected; indeed, frequently-called macros should be copied to the
file they are used in for better performance, because each call of a macro in a
different file causes that file to be re-opened again.

> What are other things that can be done to reduce parse times (aside from
> reducing file sizes)?

Well... reducing file sizes even more, I guess :)

As for the mesh2 files, stripping any unnecessary blanks or leading zeros may
help (e.g. "0.123" can be written as ".123"), and likewise reducing the
precision of floating points (e.g. normal vectors probably don't need more than
2 or 3 digits); in addition, if the mesh contains UV coordinates you mach check
whether you need them.

If you have multi-textured mesh objects but don't need to use them in CSG
intersections or differences, you can decompose them according to texture, so
you don't have to specify texture on a per-triangle basis, eliminating all the
texture_index data. If you have single-textured mesh objects, make sure they're
exported without texture_index data and use a single texture statement instead.


Aside from those mesh2 objects, try to eliminate loops. With loops you can't do
without, try reducing the number of statements inside the loop. Try to reduce
the number of variable assignments. Try to eliminate function or macro calls in
loop conditions.

For frequent computations, use functions instead of macros where possible.

When generating scene description statements "on the fly" in time-demanding
loops, try writing those statements to a file instead, and then including that
file, and use a flag to control whether that include file is re-generated or
the existing version used.


Try reducing textures to the resolution you really need. Loading of
high-resolution textures can take some time, too (recognizable by the
parsed-tokens counter stalling).



> I know in the past there was talk about a preparsed, binary format.  Has anyone
> been doing anything with that lately?

The talk was about a new SDL for POV-Ray 4.0; we're not really there yet ;)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > I'm working on a fairly complicated model that contains both mesh2 and povray
> > primitives...

> That's to be expected; indeed, frequently-called macros should be copied to the
> file they are used in for better performance, because each call of a macro in a
> different file causes that file to be re-opened again.

Already done.

> > What are other things that can be done to reduce parse times (aside from
> > reducing file sizes)?

> Well... reducing file sizes even more, I guess :)
>
> As for the mesh2 files, stripping any unnecessary blanks or leading zeros may
> help (e.g. "0.123" can be written as ".123"), and likewise reducing the
> precision of floating points (e.g. normal vectors probably don't need more than
> 2 or 3 digits); in addition, if the mesh contains UV coordinates you mach check
> whether you need them.
>
> If you have multi-textured mesh objects but don't need to use them in CSG
> intersections or differences, you can decompose them according to texture, so
> you don't have to specify texture on a per-triangle basis, eliminating all the
> texture_index data. If you have single-textured mesh objects, make sure they're
> exported without texture_index data and use a single texture statement instead.

This I'll look into - I'd have to come up with something to do it by automated
means.  The majority of the meshes have a single texture, with one entry per
face instead of 3.  They are all "stripped" of unnecessary UV data, but I could
pull the texture_list

> Aside from those mesh2 objects, try to eliminate loops. With loops you can't do
> without, try reducing the number of statements inside the loop. Try to reduce
> the number of variable assignments. Try to eliminate function or macro calls in
> loop conditions.
>

No loops, but I should go back through and pre-compute anything that has a fixed
value.

> For frequent computations, use functions instead of macros where possible.
>
> When generating scene description statements "on the fly" in time-demanding
> loops, try writing those statements to a file instead, and then including that
> file, and use a flag to control whether that include file is re-generated or
> the existing version used.

That doesn't apply in this case, but it does have me thinking about using a RAM
disk for rendering animations - parsing speed concerns seem to be mainly around
disk I/O hmmm...

> Try reducing textures to the resolution you really need. Loading of
> high-resolution textures can take some time, too (recognizable by the
> parsed-tokens counter stalling).

I'd forgotten abut that, since I am still placing geometry and haven't put in
the image maps or height_fields yet... More to look forward to!

> The talk was about a new SDL for POV-Ray 4.0; we're not really there yet ;)


That's ok, I doubt I'll be finished with this model before then ;)
Of course, when I do finally finish, I'll make these issues someone else's
problem by putting the model in Object Collection.

-Reactor

Post a reply to this message