In article <3c798771@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> If you have a spline with 3000 control point and you expand the array by 32
> per expansion, then you'll have the array copied almost 100 times with an
> average of about 1500 elements copied each time, which is in total about
> 150000 elements copied. If however you expand by 10 each time instead,
> you'll have 4 expasions at most, with no more than 1111 elements copied in
> total. That should parse more than 100 times faster. The memory you save
> with your method really isn't worth that.

I'm not going to write a 3000 point spline by hand, and the macros 
aren't that necessary for automatically generated splines. But just 
don't hard code the step value, the user could tune it for their scene 
then, if it really parses too slow. Actually, make both the initial and 
step values user-defined...they can set the step to 1000 or the initial 
size to 3000, and not waste 7000 array positions for the 3000 point 
spline.
My guess is most splines will be in the 10's or low 100's, not 1000's.


> Statistically, the most likely value of "big enough" will increase as the
> number of elements increase. Thus you multiply with a value every time
> rather than adding a fixed amount.

I'm not so sure this is true. Past a point, the bigger the spline, the 
less likely it is to get 10 times bigger, or even twice as big.


> > Also, I don't think this is a very time-critical area...
> 
> I think it is. You can easily imagine scenes with hundreds of different
> splines.

More of a requirement for memory efficiency there as well...
I just don't think the spline code would be that slow. 100 times a small 
number isn't a very big number...why don't we do some actual tests?

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message