dtaidistance | Time series distances : Dynamic Time Warping | Time Series Database library

I assume the code of both implementations are correct and as been carefully checked (otherwise the benchmark would be pointless).

The issue likely comes from the compilation time of the function. Indeed, the first call is significantly slower than next calls, even with cache=True. This is especially important for the parallel implementation as compiling parallel Numba code is often slower (since it is more complex). The best solution to avoid this is to compile Numba functions ahead of time by providing types to Numba.

Besides this, benchmarking a computation only once is usually considered as a bad practice. Good benchmarks perform multiple iterations and remove the first ones (or consider them separately). Indeed, several other problems can appear when a code is executed for the first time: CPU caches (and the TLB) are cold, the CPU frequency can change during the execution and is likely smaller when the program is just started, page faults may need to be needed, etc.

In practice, I cannot reproduce the issue. Actually, p_calc is 3.3 times faster on my 6-core machine. When the benchmark is done in a loop of 5 iterations, the measured time of the parallel implementation is much smaller: about 13 times (which is actually suspicious for a parallel implementation using 6 threads on a 6-core machine).

It appears the solution in my case was to include the index in the array. For example, if your data looks like this:

There is no answer.

1. MSVC

I have sent feedback to them, yet I did not get any reply. A Python developer assured that they know about this size issue anyway and do not like it either. The only chance is a change from MSVC developers themselves. It is unlikely, but not impossible, that the size will be reduced in future releases by the MSVC team.

1. Python distutils workaround

The Python community will not provide a distutils workaround, see https://discuss.python.org/t/imitate-visual-c-with-mingw-or-other-c-compilers-for-python-packages-based-on-visual-c/4609/11.

Quote from the Python forum:

There was a workaround until Python 3.4 which might also be an approach now: Use MinGW compiler till Python 3.4 by adding a “distutils.cfg” to the folder “\Lib\distutils” in Python install directory. It would be nice to have that MinGW “distutils.cfg” workaround for the recent Python versions as well.

Now it turns out that distutils will not be a realistic workaround.

• There is no one who will work on it. A Python developer who was involved in the project before: Maybe there is ...

... someone else who might offer to help. But I wouldn’t be too optimistic.

• And a deprecation issue:

As an aside, now that setuptools has fully taken on distutils, we’ll be deprecating it in the standard library (soon). So this request in future would have to be made to each project implementing a build tool.

Everything is correct. As per the docs:

The result is stored in a matrix representation. Since only the upper triangular matrix is required this representation uses more memory then necessary.

All diagonal elements are 0 the the lower triangular matrix is the the same as the upper triagular matrix mirrored at the diagonal. As all these value can be deducted from the upper triangular matrix they aren't shown in the output.
You can even use the compact=True argument to only get the values from the upper diagonal matrix concatenated into a 1D array.

You can convert the result to a full matrix like this: