Latency Profiling in Python: From Code Bottlenecks to Observability
quant.engineering
Latency Profiling in Python: From Code Bottlenecks to Observability
1–10 of 12 posts
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#2Why even bother with sampling profilers in Python? You can do full function traces for literally all of your code in production at ~1-10% overhead with efficient instrumentation.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#3Why even bother with sampling profilers in Python? You can do full function traces for literally all of your code in production at ~1-10% overhead with efficient instrumentation.
That depends on the code you're profiling. Even good line profilers can add 2-5x overhead on programs not optimized for them, and you're in a bit of a pickle because the programs least optimized for line profiling are those which are already "optimized" (fast results for a given task when written in Python).
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#4Why even bother with sampling profilers in Python? You can do full function traces for literally all of your code in production at ~1-10% overhead with efficient instrumentation.
That depends on the code you're profiling. Even good line profilers can add 2-5x overhead on programs not optimized for them, and you're in a bit of a pickle because the programs least optimized for line profiling are those which are already "optimized" (fast results for a given task when written in Python).
It does not, those are just very inefficient tracing profilers. You can literally trace C programs in 10-30% overhead. For Python you should only accept low single-digit overhead on average with 10% overhead only in degenerate cases with large numbers of tiny functions [1]. Anything more means your tracer is inefficient.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#5Earlier quoted context omitted.
That depends on the code you're profiling. Even good line profilers can add 2-5x overhead on programs not optimized for them, and you're in a bit of a pickle because the programs least optimized for line profiling are those which are already "optimized" (fast results for a given task when written in Python).
It does not, those are just very inefficient tracing profilers. You can literally trace C programs in 10-30% overhead. For Python you should only accept low single-digit overhead on average with 10% overhead only in degenerate cases with large numbers of tiny functions [1]. Anything more means your tracer is inefficient. [1] https://functiontrace.com/
That's... intriguing. I just tested out functiontrace and saw 20-30% overhead. I didn't expect it to be anywhere near that low.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#6> The trading system reports an average latency of 10ms
Python is a bad choice for a system with such latency requirements. Isn't C++/Rust preferred language for algorithmic trading shops?
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#7> The trading system reports an average latency of 10ms Python is a bad choice for a system with such latency requirements. Isn't C++/Rust preferred language for algorithmic trading shops?
Depends... not all kinds of trading are THAT latency sensitive.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#8> The trading system reports an average latency of 10ms Python is a bad choice for a system with such latency requirements. Isn't C++/Rust preferred language for algorithmic trading shops?
Why is Python automatically a bad choice? We've build some turbodbc + pandas which beats Go when dealing with a logic azure sql server for massive analtyic flows. I'm not sure if it's faster or slower than Rust, but it's basically C++ fast, though it obviously uses a lot more memory. Fortunately we live in a world where "a lot more" is like $5 a year.
I don't disagree with you that Python might be a wrong choice for algorithmic trading, but I do think it depends. We did our stuff with turbodbc rather than pyodbc which is used everywhere else, specifically because we analysed our bottlenecks.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#9What a weird AI generated blog.
What's the point of hosting a blog with a series of superficial posts? There's no promotion of anything, no personal brand, no advertising, just mediocre writing and AI graphics with no actual benchmarks or code.
Re: Latency Profiling in Python: From Code Bottlenecks to Observability
#10This looks awfully AI-Generated