In article <3e1d431a@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> In this respect, I can suggest an easy, virtually free (in terms of efforts)
> solution: (i) use getc() instead of fgetc(), and (ii) always #include
> <stdio.h> in the modules that use getc(). In such a case, you end up using
> very efficient macro instead of a function; five to ten times or so as fast;
> no side effects. This is an ANSI behaviour, not a VC/GCC/etc. hack.

This is only true for ISO C, not ISO C++.  In C++ all C macros are required
to be functions; and when using "cname" instead of "name.h" headers they are
even placed in the std namespace.  POV-Ray 3.5 is a C++ program.

Apart from that the lastest revision of C, ISO C 99 explicitly notes that
getc may be either a function or a macro.  In reality, it is even so that
some libraries implement it in terms of exactly the same code fgetc uses...

> I am still a bit suspicious as to the real bottlenecks though... but you're
> right, there is no point in arguing w/o profiling it. One day I will do this
> again, for sure... As you did read my povpro info, you should be aware that
> I did that (profiling) in the past, but I have to admit that I did not pay
> any attantion to parsing step at the time, at all. Well, one day, when I
> have enough time on my hands...

Takes a scene that takes relatively long to parse like isocacti.pov and
render only a very small image.  You still get some trace and isosurface
stuff in there, but still the result will be clear.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message