Hi, Kurt has recently proposed a patch for 1D-FFT which is much faster than our current impl, while still passing the tests (of course). Am I likely to hurt anyone's feelings if I replace the old impl by the new impl?
Also, I think that one of the reasons why our previous implementation was so slow is because it used internally Complex objects. Since these objects are immutable, we end up creating *a lot* of small objects. Apparently, the GC and JIT are not so good at that ;) (not being an expert, I'm not sure that the culprit is indeed the JIT or the GC... but surely someone is to be blamed). I remember we recently had this conversation on the ML: one of Gilles or Luc argued that for very low-level algorithms, it didn't really matter if the parameters were passed as "very crude" objects, since it was most likely that the user would have to write an adapter to its own data format. So I would suggest we give up Complex[] altogether in the interface of FFT, and replace it with double[] arrays, with the following layout : data[2 * i] = real part data[2 * i + 1] = imaginary part. What do you think? Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
