austin-python icon indicating copy to clipboard operation
austin-python copied to clipboard

Progress output during format conversion

Open sparrowt opened this issue 1 year ago • 5 comments

Description

It would be lovely to have some CLI progress output during format conversion, otherwise it's hard to know if something is hung / how long you're going to need to wait.

I've thought this before but just filing this for now before I forget - not sure I'll have time to submit a PR at the moment.

Steps to Reproduce

  1. Record a significant sized austin trace (e.g. I've had some ~5GB when trying to diagnose a memory leak for example)
  2. Run austin2speedscope trace.austin trace.json

Expected behavior: Some progress output so that I don't give up / have an idea how much time I have to fill with another task

Actual behavior: Zero console output

Reproduces how often: 100%

Versions

austin-python==1.7.1

sparrowt avatar Dec 17 '24 16:12 sparrowt

I've thrown some absolute basics here: https://github.com/P403n1x87/austin-python/compare/main...sparrowt:show-progress

It doesn't tell you how far through you are relative to any total, but at least you can see that things are still happening.

sparrowt avatar Dec 17 '24 17:12 sparrowt

That's a very good point. Not having any feedback when it takes a long time to convert a big file is not ideal. I think a byte-based approach might be the way to go here. We could add a progress attribute to both AustinFileReader and MojoFile that can be used by a background thread to display the progress. WDYT?

P403n1x87 avatar Jan 08 '25 14:01 P403n1x87

Actually I did add some more to https://github.com/P403n1x87/austin-python/compare/main...sparrowt:show-progress since my comment above, so the 2nd commit now prints out bytes-based progress without any threading (though no Mojo yet).

I can open a PR from that branch if you think it's an acceptable approach

sparrowt avatar Jan 10 '25 13:01 sparrowt

I can open a PR from that branch if you think it's an acceptable approach

Ah that would be great 🙏 . The reason I mentioned threads is that I was envisioning a generic solution that can be used with any parsing class. Benefits that I can think of would be:

  • keep presentation logic separate from the data model
  • code re-use
  • works for both TUIs and GUIs (potentially any UI really)

Do you reckon we can go in this direction with your changes?

P403n1x87 avatar Jan 11 '25 10:01 P403n1x87

Yeah that's a fair point - currently I don't have time to dedicate to this any more (sorry!) but I've opened https://github.com/P403n1x87/austin-python/pull/32 for now if you're willing to consider it as an interim / stepping stone.

sparrowt avatar Jan 16 '25 13:01 sparrowt