Parrothead wrote:
This Assumes "Cache Database in available memory" is checked in setup otherwise
Actually no, in my tests I had it off.
Parrothead wrote:
Sector.warpcount[x] and getsectorparameter "x" "FIGSEC" $x take alot of time to fetch from the hard drive. I find multidementional static array's are the fastest way to retrieve the pre-filtered data.
Hrm... That doesn't match my testing.
1,000,000 iterations of:
Code:
setVar $i 1
while ($i <= SECTOR.WARPCOUNT[9826])
setVar $blah SECTOR.WARPS[9826][$i]
add $i 1
end
Where 9826 is a 6-way (stardock of a test game) takes
19508 ms. That's ~.02ms per iteration. That's still very
tiny, there's no sense in caching that. I suspect you won't
pick up much (if any) speed by doing that.
GetSectorParameter depends on where in the parmlist the
parameter is. The 10th parm, yes. The 1st, no. Here's my
testing for figsec (initialized as the first parm in each sector).
1,000,000 iterations of:
Code:
setVar $i 1
while ($i <= SECTOR.WARPCOUNT[9826])
setVar $blah SECTOR.WARPS[9826][$i]
getSectorParameter $blah "FIGSEC" $isfigged
add $i 1
end
Took 23604ms. So... .023604ms per iteration. That's a
difference of .004096ms per iteration. We're talking about
a really really tiny amount.
Now that is with cache db in mem turned on. So let me turn
it off and rerun. How much does it go up? Total, 1m iterations
in 33418ms. That's 9814ms per 1m iterations. For a total of
.0098ms per iteration added by doing a non-cached parm get.
Overall, parms versus no parms. Cached versus not cached,
it's not even 1ms per iteration difference.
Now, like I was saying earlier, the setparm takes a little more...
1m iterations of:
Code:
setVar $i 1
while ($i <= SECTOR.WARPCOUNT[9826])
setVar $blah SECTOR.WARPS[9826][$i]
setSectorParameter $blah "FIGSEC" TRUE
add $i 1
end
Took 59796ms. While still tiny per iteration, it's quite a big
difference. In fact just moving that one thing took out the
bulk of processing time from the pre-torp calculation, like I
said last post.
Now I grant you, my PC is a little faster than average. And
my vbox drive actually outperforms most sata drives, but
even if you multiply the time it takes by a factor of 10, it's
still a small amount of processing.
There is very little difference between pre-processing and
post-processing. When I released qfot originally, I knew this
because I had done testing with EP while he was working on
2.04's parms. It's still a very effective script, less than 1ms
difference between yours and mine.
The difference only comes when you have a very slow, very
fragmented PATA drive and aren't caching your DB, and figsec
is like the 10th parm on the parm list. That is why I moved to
a pre-cached fig database on my private vers, it removes the
one major bottleneck in the system. Still, in most cases, I
picked up no speed improvement by doing so.
The real improvements in fotoning comes with the use of the
bot. You may pick up 1ms or 2ms speed difference at the
extremes of coding, but with ping you can pick up 20, 30ms,
50ms improvements. Distributing the torper as a bot module
and allowing your fastest torpers to shoot... that's the biggest
improvement around.