Hi,
First the good news - under the new, soon-to-be-released version, startup time went from 25s to 1s with no modifications!
As for the list version being slower, well, list's are slower than arrays so it will be a little slower.
A couple of factors are likely to be compounding this too. For one, much of the time rays are hitting 'nothing', so the overhead of lists will be more apparent. If each ray hit 'something', than the difference would likely be much less profound.
And looking at the code, I would also guess that some kind of 'critical point' is being reached in the list version, which is causing the compiler to spill a bunch of registers or something. The array version is pretty much, 'call free' in it's outer loop.
It might also be an idea to rewrite it in 'strict' mode, moving locals into the scope in which they actually appear. This can help the compiler reuse registers more efficiently.
First the good news - under the new, soon-to-be-released version, startup time went from 25s to 1s with no modifications!
As for the list version being slower, well, list's are slower than arrays so it will be a little slower.
A couple of factors are likely to be compounding this too. For one, much of the time rays are hitting 'nothing', so the overhead of lists will be more apparent. If each ray hit 'something', than the difference would likely be much less profound.
And looking at the code, I would also guess that some kind of 'critical point' is being reached in the list version, which is causing the compiler to spill a bunch of registers or something. The array version is pretty much, 'call free' in it's outer loop.
It might also be an idea to rewrite it in 'strict' mode, moving locals into the scope in which they actually appear. This can help the compiler reuse registers more efficiently.