POV-Ray : Newsgroups : povray.newusers : Should Parsing really take that long? How to speed it up? : Re: Should Parsing really take that long? How to speed it up? Server Time
29 Apr 2024 05:54:21 EDT (-0400)
  Re: Should Parsing really take that long? How to speed it up?  
From: clipka
Date: 6 Dec 2015 07:11:30
Message: <566425f2$1@news.povray.org>
Am 05.12.2015 um 08:23 schrieb ILM:

> I edited the pov file in a text editor and removed the extra 30.000 declare
> lines. Unfortunately that did not reduce the parsing time.
> 
> Furthermore I tried the following:
> - Changed the png file to a 1x1 px file. Parsing now only takes 40 seconds.
> - Changed the png file to a 1x1 px file AND removed the 30.000 declare lines.
> parsing now takes about 15 seconds.

Are you absolutely, positively sure you removed all the 30.000 "#declare
cube=pigment { ... }" lines (except the first one of course)?

That would be a very odd finding.


Obviously, what bogs down the parsing of your scene has something to do
with the handling of PNG -- more specifically, the handling of the
image's actual data.

One of the most time-consuming operations in handling image file data
would typically be the process of getting it from disk into memory. This
is something POV-Ray does at the very moment it encounters the
"image_map { png ... }" statement. Having a lot fewer of those
statements /should/ have /some/ effect on parsing time.

If that is not the case /at all/, we'd have to conclude that some other
"expensive" stuff happens with the image data further down the line; the
only thing that would make sense there would be that the 30,000-fold
duplication of the declared object might also duplicate the texture list
each time, which in turn might duplicate the texture, which in turn
might duplicate the pigment, which in turn might duplicate the
image_map, which in turn might duplicate the image.

In fact the duplication of a mesh2 object /does/ duplicate the texture
list, which in turn /does/ duplicate the texture, which in turn /does/
duplicate the pigment, which in turn /does/ diplicate the image_map.

But here's where it stops: When an image_map is duplicated, this does
/not/ copy the image data; it simply copies a pointer to the actual
image data.

Thus, the overhead of all the duplication should be constant with
regards to the image size; whether the image is 1x1 pixels or
10,000x10,000 pixels in size should have no effect whatsoever on the
time it takes to duplicate those 30,000 mesh2 objects.


I'll do a few tests to see whether I'm overlooking something about the
mechanism behind image_map duplication, but at the moment the hypothesis
that makes most sense to me is that you made some trivial mistake when
testing with the 30,000 "#declare cube=..." lines removed, such as using
an external editor to make the change and forgetting to save before
rendering.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.