----- Original Message ----- From: "Sam Tregar" <[EMAIL PROTECTED]>
> > Does shortening the arrays mean that you might have to grow them with > realloc() later under some circumstances? No. I just set them to be large enough to cover all eventualities. There's no dynamic allocation or freeing of memory anywhere in the function. It's just a multiple-precision arithmetic routine, where the arguments are passed to the inline stack, read from there, operated on, and the answer pushed back onto the stack. If I've defined ARR to be 2500, but only the first 200 values of an array get re-assigned, then the remaining 2300 elements (all of which are zero) never even get looked at. The array that gets passed from perl to the stack contains around 2100 elements (in the case I've been looking at), all of them integers. Maybe it's time to grab the typemap and associated files from Math::FFT so that I can pass by pointer. But surely, having a stack of 2100 elements cannot be responsible for *this particular* strange behaviour ?? I've also run with larger numbers, where the stack contains 10500 elements, and the routine still completes in the expected time - no clicks, groans or whimpers. I interpret that to mean that 2100 is nowhere near big enough to be posing load problems. > I suggest stepping through your > code with a debugger and possibly using a profiler to find out where the > time is going. > Well ..... I know how to debug C with 'printf' and how to time perl with 'use Benchmark', but beyond that .... :-) So it looks like I have some work to do before I can follow your (and Brian's) advice. I'll try cleaning up some code first and see if that yields anything. (There's some tidying up that should be done, anyway.) If that fails to produce anything, then ...... oh, dear ..... work!! This is something that I will *have* to get to the bottom of. (Though I should point out that this falls into the category of 'hobby' - not 'saving the world'.) I get the feeling that there could well be *more* than 250ms at stake :-) Thanks Sam. Thanks Brian. Cheers, Rob
