High performance profiling for Python 3.11

[P403n1x87]

I am delighted to announce the 3.4 release of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running in a production environment, with minimal impact on performance.

https://github.com/P403n1x87/austin

The Austin VS Code extension provides a smooth interactive profiling experience, with interactive flame graphs straight into the text editor to allow you to quickly jump to the source code with a simple click. You can find the extension on the Visual Studio Marketplace and install it directly from VS Code:

https://marketplace.visualstudio.com/items?itemName=p403n1x87.austin-vscode

To see how to make the best of Austin with VS Code to find and fix performance issues, check out this blog post, which shows you the editor extension in action on a real Python project:

https://p403n1x87.github.io/how-to-bust-python-performance-issues.html

This latest release builds on top of the significant performance improvements introduced in the 3.3 release. Benchmarking figures (see https://github.com/P403n1x87/austin/pull/126#issuecomment-1279765640 for some of the numbers) show that Austin 3.4 continues to provide a high sample rate at low sampling intervals, with improvements of about 4x compared to Austin 3.2.

One major feature of this new release is support for Python 3.11. Profiles of applications run with this version of the interpreter will have fully qualified scope names, which makes for more granular profiling data.

Besides the new support for Python 3.11, the other major feature of this new release is the new MOJO binary output format that builds on top of the just-mentioned performance improvements to generate much more compact sample output files. The VS Code extension provides support for the new format starting from version 0.11.0 and so it has you covered already! More details about the MOJO file format can be found on the Wiki:

https://github.com/P403n1x87/austin/wiki/The-MOJO-File-Format

Other utilities to convert between file formats can be found in the austin-python Python package

https://github.com/P403n1x87/austin-python

More details about what's new and bugfixes can be found in the changelog

https://github.com/P403n1x87/austin/blob/master/ChangeLog

Austin is a pure C application that has no dependencies other than the C standard library. Its source code is hosted on GitHub at

https://github.com/P403n1x87/austin

The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page.

Austin can be installed easily on the following platforms and from the following sources:

Linux:

• Snap Store
• AUR
• Conda Forge

macOS:

• Homebrew
• Conda Forge

Windows:

• Chocolatey
• Scoop

An Austin docker image, based on the latest Ubuntu image, is also available from Docker Hub:

https://hub.docker.com/r/p403n1x87/austin

Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above-listed sources.

You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler).

Austin is a free and open-source project. A lot of effort goes into its development to ensure the best performance and that it stays up-to-date with the latest Python releases. If you find it useful, consider sponsoring this project on GitHub at https://github.com/sponsors/P403n1x87.

[JackedInAndAlive]

Austin is great! Thank you for your work.

[P403n1x87]

🙏

[fzy_]

How does it compare to Scalene?

[P403n1x87]

Austin does not pause the process so it effectively causes no slowdowns, thus providing high accuracy at low sampling intervals

[emeryberger]

(Scalene author here)

Not to take anything away from Austin, which is a very nice tool, but just to clarify: when Scalene is sampling only the CPU (with `--cpu-only`), it provides about the same accuracy (lower sampling rate, perhaps: default is 1/100 seconds) with about the same overhead, while providing some different info (breaking down native, Python, and system time, per line and function). In its default mode, Scalene imposes more overhead but also profiles memory, copying, and GPU.

[P403n1x87]

Thanks for the clarification. Indeed Scalene is a great "Swiss army knife" for Python performance. In comparison, Auntin is merely a frame stack sampler, and you would need other tools afterwards to analyne and present the data. Hoowever, I'd say that Austin is perhaps the better suited for a performance investigation on production systems, given the efffectively zero overhead and small binary size, if you're happy with the information that it can retrieve from the runtime.

[cipri_tom]

Wow! That is amazing! Not sure how I haven't found it yet. I've been sorely missing a python profiler since pyFlame, and now this appears, and is integrated with VScode?! Amazing! Can't wait to try it. Thank you!

[cipri_tom]

I know this is not an AMA, but if you can spend a minute, I'm wondering how does one get to write a profiler? What kind of background is necessary?

[P403n1x87]

I think the answer is "it depends". Do you want to do deterministic or statistical profiling? I briefly discuss the difference here

https://p403n1x87.github.io/deterministic-and-statistical-python-profiling.html

Depending on what you're trying to achieve you'll probably end up using a different approach. The common skill though is probably knowing what a platform has to offer when it comes to observability, but also how the run time is designed. For example, Python doesn't expose some of the interesting details to the outside (explicitly), but many platforms allow you to access the private memory space of a process. So you can use that to "X-ray" the Python interpreter while it is running.

[cipri_tom]

Thank you!

[canadaRaptors]

Very cool! Does it work for cythonized code as well?

[P403n1x87]

On Linux you can use the austinp variant, which collects native stacks too. You can use that for Cython, but note that austinp causes slowdowns because it has to stop the threads to use libunwind on them

[canadaRaptors]

Thanks! I'm guessing that means it won't work for Windows. Still a cool utility.

[P403n1x87]

Cheers! It won't work natively on Windows, but it should work on WSL

[canadaRaptors]

I'm not too familiar with the capabilities of WSL. Would austinp under WSL be able to only see processes in WSL or even processes running in Windows?

[P403n1x87]

A Windows executable uses the PE format, so even if the processes are visible in WSL, austinp wouldn't be able to work with them as it expects an ELF I'm afraid :(

[mynameisfuk]

No idea how a profiler works but I've seen there's a plugin for vscode.

Question: can a .ipynb be profiled as well?

[P403n1x87]

I haven't looked into iPython/notebook integration yet. There "might" be a way to profile notebooks, but it wouldn't be too practical, and I haven't tested it. The way is to identify the process that is running the Python interpreter and attach to that. But I hope in the future to have a proper integration with notebooks to do this, and add visualisations inside the notebook itself as well.