Latency Profiling in Python: From Code Bottlenecks to Observability(quant.engineering) |
Latency Profiling in Python: From Code Bottlenecks to Observability(quant.engineering) |
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.
Python is a bad choice for a system with such latency requirements. Isn't C++/Rust preferred language for algorithmic trading shops?
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.
"This license allows you to use and share this software for noncommercial purposes for free and to try this software for commercial purposes for thirty days."
This is not an open source license. "Open Source" is a trademarked term meaning without restrictions of this kind; it is not a generic term meaning "source accessible".
You can also just use perf, but it does require an extra package from the python build (which uv frustratingly doesn't supply)
I used FunctionTrace as a example and evidence for my position that tracing Python is low overhead with proper design to bypass claims like: “You can not make it that low overhead or someone would have done it already, thus proving the negative.” I am not the author or in any way related to it, so you can bring that up with them.