Disclaimer: Resolution of this example is likely of extremely limited personal use to me since I can just pick the faster of the two versions. However, I thought that it might be helpful for numba core development purposes since njit should make things faster and seeing cases where it doesn’t seeme…

Well, I didn’t split in files, and I got rid of all the decorator distraction (hopefully correctly). This is the code: import numpy as xp from numba import njit def get_d_1(K, x, dx, xt): d = K[0] if 0 < K[1].size: d += intk1d1o(K[1], dx, xt) if 0 < K[2].size: d += intk…

Thanks for the insights. And, you’re right, there’s some serious overhead as these functions are called more frequently. This partials function is potentially called hundreds of thousands of times so microseconds add up. So, I figured it’d be worth trying to throw njit at it. The idea of crossin…

The best solution to this issue (wherever reasonably possible) is to compile as “high up” in the call chain as possible. Type inference is only done when a jitted function is called from interpreted code, but everything is static when calling jitted code from within other jitted code (afaik). So you…

[image] Hannes: The best solution to this issue (wherever reasonably possible) is to compile as “high up” in the call chain as possible the cost of type inference on short running functions it’s something I didn’t realize fully until last week. The problem is that going too high up the chain …

Yes the balancing act is real, I have made the painful encounter with non-jittable callers on a few occasions :’) An added advantage of compiling higher up may be additional compiler optimisations (specifically inlining and maybe even loop fusion?)

Yeah, and that weighs against the flexibility. I have a variable that represents an infinite series of vectors of increasing shape, K = [1, (10), (10,10), (10,10,10)]. I arbitrarily stop at 3rd order, but it’s nicer to use K as a variable without going into every function and typing K0, K1, K2, K3…

[image] randompast: K = [1, (10), (10,10), (10,10,10)] have you tried Siu’s trick of setting the other dimensions to 1? ie K = [np.ones(0), np.random.uniform((1,1,10)), np.random.uniform((1,10,10)), np.random.uniform((10,10,10)) ] in that way you should be able to com…

I haven’t yet. It’s not as simple as (1,1,10) since it’s really the result of a spline function. That said, I used the profile tree to identify which functions were jitted and which weren’t. I essentially had everything jitted, so I’m crawling up the line and just reworking the api using K1, K2, …

Hm, looks like I can do a.reshape((1,1,10)) so what I said about that is moot.

3x slowdown in parent function when applying njit

Numba Community Support

randompast July 15, 2020, 9:55pm 3

Odd, it definitely compiles and runs for me. I can’t upload the files directly. I’m using python 3.6.9 and numba 0.50.0.

Topic		Replies	Views
Why am i getting different performance speeds for the "same" decorator? Community Support	11	1025	March 4, 2021
Performance question / issue on particular problem Support: How do I do ...?	19	1225	January 20, 2021
Profiling with a decorator and @njit Community Support	28	3938	May 30, 2023
Nested numba functions slow down execution and cannot be inlined Community Support	6	2681	February 7, 2023
Major slow down when adding one more layer of function Numba	3	219	September 28, 2023

3x slowdown in parent function when applying njit

Related topics