Add fourier-transform to benchmarks

[danigb]

I've added the fourier-transform to the benchmark (related to #1). It seems to be the fastest but is unfair because only works with real signals and have no inverse operation.

This is the results of the benchmark in my computer:

===== table construction =====
    fft.js x 1,266 ops/sec ±1.98% (86 runs sampled)
  Fastest is fft.js
===== transform size=2048 =====
    fft.js x 17,473 ops/sec ±2.66% (87 runs sampled)
    jensnockert x 3,900 ops/sec ±0.96% (90 runs sampled)
    dsp.js x 14,500 ops/sec ±1.10% (87 runs sampled)
    drom x 11,076 ops/sec ±1.05% (86 runs sampled)
    fourier-transform x 23,630 ops/sec ±0.99% (90 runs sampled)
  Fastest is fourier-transform
===== transform size=4096 =====
    fft.js x 8,835 ops/sec ±0.87% (88 runs sampled)
    jensnockert x 2,997 ops/sec ±1.14% (89 runs sampled)
    dsp.js x 5,053 ops/sec ±0.78% (92 runs sampled)
    drom x 5,143 ops/sec ±0.90% (89 runs sampled)
    fourier-transform x 11,091 ops/sec ±0.92% (89 runs sampled)
  Fastest is fourier-transform
===== transform size=8192 =====
    fft.js x 3,675 ops/sec ±0.93% (88 runs sampled)
    jensnockert x 833 ops/sec ±7.40% (81 runs sampled)
    dsp.js x 2,095 ops/sec ±0.76% (90 runs sampled)
    drom x 2,390 ops/sec ±0.85% (90 runs sampled)
    fourier-transform x 4,573 ops/sec ±0.90% (92 runs sampled)
  Fastest is fourier-transform
===== transform size=16384 =====
    fft.js x 1,792 ops/sec ±0.96% (89 runs sampled)
    jensnockert x 664 ops/sec ±1.21% (87 runs sampled)
    dsp.js x 704 ops/sec ±0.89% (90 runs sampled)
    drom x 1,094 ops/sec ±0.79% (89 runs sampled)
    fourier-transform x 1,936 ops/sec ±0.97% (92 runs sampled)
  Fastest is fourier-transform

Thanks for the library, the code looks very clean and easy to understand (and I've read a lot of implementations lately). Looking forward #2 to improve speed. And probably is a good idea to have some tests to check the results (it looks like different implementations have slightly different values)

Congrats.

[indutny]

Thanks for opening this! Let's wait until this lib will support all-real-input mode before adding this benchmark.

Btw, numbers are not so distant now with the latest changes 😉

===== table construction =====
    fft.js x 1,247 ops/sec ±1.75% (87 runs sampled)
  Fastest is fft.js
===== transform size=2048 =====
    fft.js x 31,000 ops/sec ±0.91% (92 runs sampled)
    jensnockert x 4,951 ops/sec ±0.73% (93 runs sampled)
    dsp.js x 22,735 ops/sec ±0.62% (95 runs sampled)
    drom x 14,318 ops/sec ±0.59% (95 runs sampled)
    fourier-transform x 31,110 ops/sec ±0.65% (92 runs sampled)
  Fastest is fourier-transform,fft.js
===== transform size=4096 =====
    fft.js x 13,899 ops/sec ±0.70% (95 runs sampled)
    jensnockert x 3,886 ops/sec ±0.58% (94 runs sampled)
    dsp.js x 7,694 ops/sec ±0.78% (92 runs sampled)
    drom x 6,667 ops/sec ±0.76% (95 runs sampled)
    fourier-transform x 14,297 ops/sec ±0.68% (92 runs sampled)
  Fastest is fourier-transform
===== transform size=8192 =====
    fft.js x 6,189 ops/sec ±0.81% (93 runs sampled)
    jensnockert x 1,163 ops/sec ±0.81% (93 runs sampled)
    dsp.js x 2,807 ops/sec ±0.72% (93 runs sampled)
    drom x 3,094 ops/sec ±0.70% (92 runs sampled)
    fourier-transform x 5,863 ops/sec ±0.68% (91 runs sampled)
  Fastest is fft.js
===== transform size=16384 =====
    fft.js x 2,783 ops/sec ±0.74% (94 runs sampled)
    jensnockert x 822 ops/sec ±0.97% (89 runs sampled)
    dsp.js x 929 ops/sec ±0.70% (92 runs sampled)
    drom x 1,407 ops/sec ±0.84% (93 runs sampled)
    fourier-transform x 2,485 ops/sec ±0.85% (94 runs sampled)
  Fastest is fft.js

[indutny]

Regarding tests - I'm cross testing against fft now.

[indutny]

Here is the link FWIW:

fft.js/test/fft-test.js

Lines 140 to 157 in 28cfc12

	it('should verify against other library', () => {
	const sizes = [ 512, 1024, 2048, 4096 ];
	sizes.forEach((size) => {
	const ex = new external.complex(size, false);
	const input = new Float64Array(size * 2);
	for (let i = 0; i < input.length; i += 2)
	input[i] = i >>> 1;
	const expected = new Float64Array(size * 2);
	ex.simple(expected, input, 'complex');
	const self = new FFT(size);
	const out = self.createComplexArray();
	self.transform(out, input);
	assert.deepEqual(out.map(fixRound), expected.map(fixRound));
	});
	});

[danigb]

Thanks for opening this!

👍

Let's wait until this lib will support all-real-input mode before adding this benchmark.

Ok, but... what is all-real-input mode?

Btw, numbers are not so distant now with the latest changes 😉

I see... good work!

Regarding tests - I'm cross testing against fft now.

Great!

I've updated the PR to your master and fix a couple of eslint errors.

[indutny]

The input for FFT is generally an array of complex values. However, if all of these values are actually real numbers - we can compute significantly less because of various constraints on the output.

[indutny]

Implemented realTransform and landed in 08a8dd9. Check out the benchmark results 😉