Having ported a decent chunk of code to work with Numba, the key is to minimize where you're interfacing with Numba. You need to be careful of inadvertently in

Having ported a decent chunk of code to work with Numba, the key is to minimize where you're interfacing with Numba. You need to be careful of inadvertently introducing new types. Especially, numba doesn't (last I checked) recognize homogenous tuples (Tuple[Foo, ...] in typing) so each new length requires recompilation. Similarly, every call is doing inference on its arguments, including Jitclass constructors. If you're making calls with a large number of arguments, you may be killing your performance gains even absent compilation. If you're trying to make code that can run with or without numba, e.g. the same logic may not run in a loop, definitely avoid jitclasses. All in all, just_temp's remark that you have to "write it like Fortran" is pretty close. The reason I found it worked was that I had a lot of business logic type stuff segregated to an early section that spat out structures that were very regular and primitive. That meant the code that had to be fast was already very Fortran like.