Sampling profilers are also useful for languages that use exceptions as some trace profilers can lose track and end up with either incorrect trees or tree nodes bundling the gap with a name that may as well be ¯\_(ツ)_/¯. I've also seen trace profilers just hang or return zero data as well as nodes in completely the wrong place. Not capturing all possible call stacks isn't a problem if you are debugging a high CPU problem. A few hundred samples is usually enough.
It's kinda wild to me that I am still using 3.8 for most projects that need the strongest compute. Kinda funy how things went the other way with deeplearning and hpc
I’m not even sure we haven’t worked together, you remind me of my favorite python CS athletes and colleagues. But I definitely clicked on this because of your shocked face in the thumbnail. Haha, you don’t do that often. Thanks for being authentic, sir! (I heard the tech details too, just had to compliment)
if you watch to the end or look closely at the profile it's not actually inspect stack where the self time happens and the slowdown occurs but in getmodule
@@anthonywritescode I would still like a video on why celery might not be the best choice. I have used celery quite extensively in production and I too would pick something lighter like dramatiq just because of the number of regressions across three or more separate libraries (kombu, billiard, celery) every version upgrade. Can't really blame the already small team of maintainers, it is a huge project that everyone uses differently.
@@anthonywritescode sorry I meant using a sampling profiler continuously. There is still some slight overhead and just with logging you get to see what happens most of the time as it happens.
