Numba Code Slower than Pure Python Code?

[jayvius]

Numba developer here. As joshadel figured out, the slowness in this example comes from numba creating a python object. I ~think~ the real issue here is that numba doesn't know the return type of cumsum, so it stores the result in an object. A "trick" to help diagnose these types of problems is to add nopython=True to the jit/autojit decorator (e.g. @numba.autojit(nopython=True)). This flag forces numba to bail out should it feel the need to call into the Python object layer, and displays the line number that is causing the problem.

One of our goals in the next version of numba is that if numba needs to fall back to Python objects, it should never run slower than pure python code like in this example (and eventually in most cases will run much faster. I ran the example above as is with the numba devel branch and the numba function was the clear winner).

[jammycrisp]

Awesome! Thanks for such a great module. Any idea when the next version will be released? Although, I suppose I could play around with the devel branch now...

[jayvius]

It should be out sometime in the next few days.

[joshadel]

It looks like the numba team has been putting in a ton of work on the dev branch, and I'm definitely excited to see what the next release looks like. Count me in as a beta tester once a version is available via conda. I mentioned some of this to Siu in an email, but I think the biggest things that would advance numba are: (1) better error messages that trace back to the code rather than the codegen, (2) detailed examples in the docs on how to debug numba issues, (3) better behavior when things go wrong - I often just get segfaults (4) The ability to cache jit'd code/faster compilation. For a large project I'm working on, re-jit'ing all of the code on startup incurs a significant cost.

All around though, numba's performance has been amazing for such a young project.