flag for unlimited --duration (maybe even default)

[drewm1980]

When py-spy launches the traced program, it would be convenient to have an "unlimited duration" option of some sort for when you want the traced program to run to completion.

Passing a large value for --duration works as a workaround, but it "breaks" the progress bar, and it's non-obvious from the --help output. The progress bar would need to be replaced with a spinner of some sort.

I usually run benchmark scripts to completion, so of course I'd vote for this to be the default behavior when --duration isn't passed, but of course everyone wants ~their use case to be the default!

Related issue that would probably also be easier with this as the default behavior:
#21

[njsmith]

I was also surprised and confused when py-spy python myscript.py only recorded 2 seconds of data from a script that ran for 5 seconds.

[benfred]

I agree that when you're getting py-spy to sample a program that py-spy itself starts, it can be weird to only sample for 2 seconds (though it seems more about right when connecting up to a pid to me). Changing the default duration to be something longer/infinite makes some sense when py-spy launches the program.

I've also been thinking of other ways of incorporating time into sampling programs, in particular balancing showing results right away and showing across the lifetime of the program.

I have a dev release here that has some work on this: install withpip install py-spy==0.2.0.dev1 and then run py-spy --serve -- python myprogram.py.

With this mode, py-spy will keep on sampling until the program ends, but you can connect up to an embedded web server right away and see a flame graph as the samples are being collected. It also lets you select the time range for samples included in the flame graph, which I think is pretty useful myself. All the assets compiled into the py-spy binary using rust-embed, served up with rouille - and the visualizations are generated with d3/d3-flamegraph.

This is still a work in progress, but I'm interested in any feedback you might have. Eventually I'm thinking this might replace the existing flamegraph generation code .

[njsmith]

though it seems more about right when connecting up to a pid to me

Another option to consider when connecting to a pid would be: collect until the user hits control-C (ideally while showing some status info on the terminal to give them a hint about whether it's gathered enough data).

With this mode, py-spy will keep on sampling until the program ends, but you can connect up to an embedded web server right away and see a flame graph as the samples are being collected. It also lets you select the time range for samples included in the flame graph, which I think is pretty useful myself. All the assets compiled into the py-spy binary using rust-embed, served up with rouille - and the visualizations are generated with d3/d3-flamegraph.

That's pretty slick!

I guess you'll still want to have some way to run this in "headless mode", where it dumps the data to some kind of file that can be collected and visualized later, or saved and sent to someone else to look at. But for most cases the workflow is quite nice...

One nitpick: the animation when configuration changes (e.g. from clicking on one of the checkboxes or moving the timeline slider) is super distracting. In the profile I was looking at, the actual changes were very small, but the animation had every box flying all over the screen before settling back to almost-exactly-what-it-was-before. Ideally, you could match up the boxes before and after, so small changes cause small animations. If not, then having no animation at all would be better, to let the user click back and forth to compare.

[martinstein]

Just noticed this discussion and I agree that an unlimited duration mode would definitely be helpful. Right now I simply set a duration that is intentionally too high, and then I hit Ctrl-C. I think an API to use it directly from code you care about would be perfect here (what I wrote at #96 (comment) ).

The main use-case that I have (and I imagine also many others) is: Profile certain endpoints in a web-application (Django, Pyramid, ...).

I'm strongly in favor of keeping the svg-output as one option (or something comparable). Having a single svg results-file that can be shared on our team-slack so that everybody can check out the performance (without having to install anything, just by opening it in a browser) and provide optimization ideas is super helpful.

[benfred]

@njsmith : I've fixed the animation when you select a different time range here pip install py-spy==0.4.0.dev0 - it should fix those issues you were seeing.