 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The following piece of code has two sections. The first section parses
in 18 seconds on this computer (p3 650m). The second section parses in
only 9 seconds!!
/*
#macro Inc ( Iter )
#local Iter = Iter + 1;
#end
#local I = 0;
#while ( I < 100000 )
Inc ( I )
#end
*/
/*
#local I = 0;
#while ( I < 100000 )
#local I = I + 1;
#end
*/
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Shay" <sah### [at] simcoparts com> wrote in message
news:3e5136ff@news.povray.org...
I should have included my explanation for posting this. I just thought
that the information might be useful for those coding certain types of
algorithms in PoV sdl.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <sah### [at] simcopartscom> wrote:
> The following piece of code has two sections. The first section parses
> in 18 seconds on this computer (p3 650m). The second section parses in
> only 9 seconds!!
This is a very known phenomenon which happens due to how macros are
parsed.
And due to how they are parsed the effect is even worse if the macro
is inside an include file instead of the current file. Try it.
If your macro performs some mathematical operation and returns the
result, the fastest way of optimizing this is to replace the macro
with a function (and then it doesn't even matter if the function
is in an include file or not).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e5150d2@news.povray.org...
|
| And due to how they are parsed the effect is
| even worse if the macro is inside an include file
| instead of the current file. Try it.
|
Woa!!!... 2 min 31 sec. This is very instructive for anyone writing an
include file.
BTW.... the code below:
(include file)
#macro Increment(Add, Loop)
#while (Add < Loop)
#local Add = Add + 1;
#end
#end
(pov file)
#include "[include file]"
#local I = 0;
#while (I < 100000)
Increment (I, 100000)
#end
as expected, only takes the original 9 seconds.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e5136ff@news.povray.org>, "Shay" <sah### [at] simcopartscom>
wrote:
> The following piece of code has two sections. The first section parses
> in 18 seconds on this computer (p3 650m). The second section parses in
> only 9 seconds!!
Yeah, the scene description language is slow. For comparison, CSDL
managed about 250000 simple loops per second on my 350MHz G3 (if I
remember right...). I haven't tested Sapphire, but it should be even
faster.
The difference is that the main POV script isn't compiled to bytecodes,
it is parsed directly, which means a lot of string operations and
jumping around the source files.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Even when compiling to some form of bytecode the second version would still
be faster, as calling a function is fairly slow relative to just calling and
increment a value. (Based upon my experience with Java bytecode).
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> In article <3e5136ff@news.povray.org>, "Shay" <sah### [at] simcopartscom>
> wrote:
>
> > The following piece of code has two sections. The first section parses
> > in 18 seconds on this computer (p3 650m). The second section parses in
> > only 9 seconds!!
>
> Yeah, the scene description language is slow. For comparison, CSDL
> managed about 250000 simple loops per second on my 350MHz G3 (if I
> remember right...). I haven't tested Sapphire, but it should be even
> faster.
>
> The difference is that the main POV script isn't compiled to bytecodes,
> it is parsed directly, which means a lot of string operations and
> jumping around the source files.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Feb 2003 13:24:44 -0600, "Shay" <sah### [at] simcopartscom> wrote:
> The following piece of code has two sections. The first section parses
> in 18 seconds on this computer (p3 650m). The second section parses in
> only 9 seconds!!
http://news.povray.org/povray.text.tutorials/21794/
http://news.povray.org/povray.text.tutorials/22153/
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e51881e$1@news.povray.org>,
"Alastair Murray" <ala### [at] hotmailcom> wrote:
> Even when compiling to some form of bytecode the second version would still
> be faster, as calling a function is fairly slow relative to just calling and
> increment a value. (Based upon my experience with Java bytecode).
True that calling a function is slower than not doing so, but the
overhead can be very small. If inline functions are supported, it could
be eliminated completely.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
