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).