Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

All good points. The "no performance cost" is indeed more like "negligible performance costs". That's because these days multicore architectures are quite ubiquitous and standard Python applications are single process. For multi-process Python applications, a busy profiler would certainly steal a good chunk of a core, so the impact might be noticeable in that case.

As for the race conditions, Austin does not introduce any pauses. Even if it did, there would be no guarantee that it paused at a "good" point, so there are no real benefits in terms of accuracy in pausing. Error rates are quite low anyway, so the actual benefit comes from not pausing at all.

Also, this kind of profiler is great because you can use it on any running Python program, which is pretty magical and very useful. (especially when it's an application you didn't write)

But it's not right for every use case: by design austin/py-spy can only really profile the whole program, and if you want to profile a specific function or endpoint in your program, something like PyInstrument https://github.com/joerick/pyinstrument (which includes Django middlewares & Flask decorators) is a lot more useful.

>you're likely to win the race, because C is faster than Python

Heh, so the only reason there's "no performance cost" is the enormous performance cost of using Python in the first place?

> you can either race with the program and hope that you read its memory to get the function stack before it changes what function it's running (and you're likely to win the race, because C is faster than Python), or you can pause the program briefly while taking a sample.

Py-spy defaults to blocking because the results can be pretty wrong otherwise: https://github.com/benfred/py-spy/issues/56 . You can see this problem profiling a program like https://github.com/benfred/py-spy/blob/master/tests/scripts/... with or without the nonblocking flag in py-spy - the nonblocking version produces garbage output.

Somewhat interestingly, this problem doesn't seem to occur with Ruby - and rbspy can get away without pausing the target program with only minor errors seen when profiling a similar function. I suspect this is because of differences between how the Ruby and Python interpreters store call stack information, but haven't had a chance to dig into the specifics.

Note that tracing profilers don't need to be high overhead - Python is slow enough that efficient tracing can be mostly hidden. For example, https://functiontrace.com tends to have <10% overhead when tracing.

I would say that a CLI is primarily for entering commands, while a TUI is primarily for viewing and interacting with data.

If a CLI program ceases to make sense when its standard-output is a physical line-printer onto a roll of paper, then it's a TUI.

Another example:

https://en.wikipedia.org/wiki/Ed_(text_editor) has a CLI, but

https://en.wikipedia.org/wiki/Vim_(text_editor) has a TUI.

Both use the terminal, but in different ways. A CLI interface uses the basic terminal functionality of writing and perhaps reading lines, or even simply accepting flags and running non-interactively. A TUI uses the terminal's advanced features, using the terminal as the basis for a kind of GUI, generally occupying the full area of the terminal.

Vim, Midnight Commander, and htop have TUIs. They rely heavily on the terminal's 'control character' features to accomplish this. apt-get has a CLI, as its interactive IO is handled with printing lines and having the user submit lines (even if it's just the letter y).

Somewhere in the middle are interfaces like bash and zsh which make light use of the terminal's advanced features for things like auto-complete, but which don't take over the whole terminal area.

I'd count non-interactive applications like gcc and sort as command-line applications, although strictly speaking you could just as well use a graphical interface to configure their flags and run commands.

See also https://en.wikipedia.org/wiki/Text-based_user_interface

Back in the MS-DOS days a TUI would be something done with Turbo Vision or Clipper, simulating GUIs with text.

God these explanations suck. Reminds me of the "two boats meet in an ocean" explanation of IRC.

A CLI (command line interface) just uses the streams to show and take in data.

A TUI uses escape codes or proprietary console commands (the latter on Windows, the former on most other things) to take control of the entire console window and display a user interface (hence Text User Interface or TUI). Usually mouse input is handled on modern systems too.

CLI refers to interacting with a program by typing commands. Commands need not come from a terminal (a terminal need not even exist). They might be just passed in from a different program.

TUI refers to interacting with a program via the terminal—the terminal is the program's user interface (think 'nano', which you can't really run without a terminal). The terminal need not interact via commands, although many TUI programs also accept commands.

I wrote a blog post about the technology behind the TUI

https://p403n1x87.github.io/the-austin-tui-way-to-resourcefu...

It's a custom resource-based framework that uses curses as back-end.

That should work

as easy as profiling with Austin itself. Just pass the pid of the web server

sudo austin-tui -Cp <webserverpid>

See https://github.com/P403n1x87/austin#examples for more details. To avoid using sudo on Linux you can do

sudo setcap cap_sys_ptrace+ep `which austin`

and then simply

austin-tui -Cp <webserverpid>

Pyinstrument might be easier to profile web requests: https://github.com/joerick/pyinstrument#profile-a-web-reques...

yep :)