Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–38 of 38 posts

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

#31

Post by junon »

Pulcinella wrote: post #13

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

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.

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

#32

Post by benfrederickson »

jvns wrote: post #4

Two other profilers that also let you spy on a running Python program: - py-spy: https://github.com/benfred/py-spy (written in Rust) - pyflame: https://github.com/uber-archive/pyflame (C++, seems to be not maintained anymore) The "no performance cost" thing is interesting: my experience writing a similar profiler is that there are a couple of things that can affect performance a little bit: 1. You have to make a lot…

> 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.

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

#34

Post by teh_matt »

jvns wrote: post #4

Two other profilers that also let you spy on a running Python program: - py-spy: https://github.com/benfred/py-spy (written in Rust) - pyflame: https://github.com/uber-archive/pyflame (C++, seems to be not maintained anymore) The "no performance cost" thing is interesting: my experience writing a similar profiler is that there are a couple of things that can affect performance a little bit: 1. You have to make a lot…

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.

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

#35

Post by mehrdadn »

Pulcinella wrote: post #13

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

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.

Post reply on HN