Displaying a progress bar results in slower completion time

Question

I write a lot of internal scripts that automate tasks for a team. In order to prevent them from wondering if the script has "halted", I display a simple progress bar for the long running tasks. I do this because I can measure the amount completed as I know the amount requiring completion prior to running. To save on the number of operations being done, I only update the progress bar every n seconds or when the task is launched/completed.

What I have found is that there is a tradeoff between:

• user experience (knowing the task is running)
• completion time of the overall script

By adding in steps to produce a progress bar and keep them aware, a task can take 2x as long.

In general, is this an expected tradeoff (perhaps not in other languages, but in Python)?

Answer 1

Trivially, any program which is doing an action plus showing a progress bar (thus two action) will be using more cpu than one doing only one action.

However, this does not mean it should be necessarily slower in wall clock time. In fact, a 2x slowdown imho seems overkill.

Some strategies include:

• Not showing a progress bar (whis is actually the default for most Unix commands, where you would need to add a verbose option)
• Providing a quiet option to disable the progress bar. This should actually be provided for UI (e.g. suppose the user will be running it from cron, or redirecting the output to a file), but would have the side-effect of bypassing the progressbar slowdown.
• Showing the progress through a different thread. Probably complex to perform with python, but normal with other languages. You have a GUI thread showing you some progress, and a worker one performing the actual work.
• Reducing the progress bar update interval / step size.
  • If you were copying a file byte-by-byte (for the sake of the argument, this is obviously inefficient), rather than redrawing the progress bar every byte, you might want to update it only after every MB copied.
  • Or by the time spent, such as setting a timer that would update the status every X seconds (again, preferably asynchronous to the main action, or on a different thread).
• By making the progress bar as cheap as possible. This could go from only outputting dots rather than a full-fledged progress bar to having the progress bar "drawn", and avoiding calculating it again on each step (you should perform the full processing on SIGWINCH, though)

In general, is this an expected trade-off

In general, I think it depends if it is possible to avoid it or not. If we are downloading one big file from the internet, you can almost always fit a proper progress bar, as the downloading will be using different resources. If you want to copy files from a remote, slow, filesystem (such as a smartphone) the browsing all the directory tree that will have to be copied so that a progress bar may7 be shown will probably be requiring resources (the bandwidth of the connection with the phone) that could be skipped if files were found and copied "as they appear".

Answer 2

That's a very nice question.

In general, we always prioritise user experience.

Example: Flights search engines could deliver results instantly but they have a longer loading as users feel more secure that they have done a thorough search.

When it comes to 2x times slower. 2x is probably ok when it is a couple of seconds and probably is terrible if it is for years. It all depends on the context of your users. If the kind of work your site is a life or death matter then faster is better, if your users are more relaxed with the time it takes and it is more important for them to know when to check back then telling them the expected time would be the best option.

Make it faster when

• Loading time is proven to negatively impact adoption, use, reliability, trust, etc.
• Speed is a matter of life or death
• Speed is a matter of making money (e.g. clients on the phone need urgent answer)

Show the loading bar if

• Multiplying the time by two doesn't create a time that would put users completely off
• You users can afford to wait while probably doing something else

More things to take into consideration Maybe you need a hybrid solution that for some processes you get the loading bar and for some, you don't.

Maybe you need alternative options: e.g. showing loading bar and tell users that by hiding it they can speed up the task, asking users if they want to receive an email notification when the task is ready etc.

In any case, the best idea would be to see what users would prefer according to their context and needs.

Good luck with it though, it is a very interesting challenge. Do post back what decision you picked in the end. :)