On Sunday August 11 2024 14:52:37 Clemens Lang wrote: >The progress bar only displays for ports with many files that take long >to activate.
Long being 500ms, the hardcoded duration threshold (which is reached more easily because of the feature itself). On not so recent hardware or simply an external HDD that's really quite short; I noticed the new feature with the first port I installed in a test MP install (ncurses). >port -q disables them. I do like to get some indication of what's going on. >Alternatively, connect the stream they print to >(stdout by default, stderr on master) to something that's not a terminal >(e.g., | cat). Yes, but as reported in my OP, the brunt of the overhead does not come from the actual displaying but from the underlying calculations and function calls. If that were not the case I would have suggested to make the duration threshold a parameter to the progress reporting mechanism. (Off the top of my head I'd say I wouldn't need to see a de/activation progressbar under 5 seconds). FWIW, I have another tweak of my own that disables just the display when the process is pushed to or launched in the background (via an addition to Pextlib) but that's not for performance reasons (the progressbar overhead should be negligible compared to the average build, plus I disable the indeterminate progress reporting as my fans give more than enough feedback that something is working). >Feel free to contribute a macports.conf option in a pull request. I considered it, but that looks like something that'll take me time to figure out so I decided to post on the users ML first to see if anyone else feels the same way as I ;)
