Por que as barras de progresso são tão imprecisas? [fechadas]

Computadores e linguagens de programação tendem a ser determinísticos e previsíveis. No entanto, as barras de progresso parecem o oposto, especialmente se a operação for complexa. Mesmo para produtos profissionais de classe mundial, algumas barras de progresso fazem pouco para refletir o progresso real de uma operação. Eu os vi ir de 10% a 90% em um salto depois de não fazer nada por 4 horas. Eu já vi algumas etapas para trás, sugerindo que um processamento extra inesperado foi descoberto.

Concedido que pode haver operações de banco de dados, processamento de rede e operações paralelas, mas parece que isso pode ser quantificado de alguma maneira e uma porcentagem estimada. Afinal, deve haver uma quantidade finita de instruções executadas para concluir uma operação. Essa codificação é simplesmente ruim ou existe alguma razão fundamental para representar o progresso difícil?

Para adicionar às respostas mais gerais até agora, posso dar alguns exemplos do meu campo em que as barras de progresso não funcionam e por quê;

Programas de projeto assistidos por computador - programas que realizam análises térmicas ou mecânica de fluidos geralmente podem ser terríveis com barras de progresso. Eles pulam para frente, para trás, dão passos inconsistentes e quase não adianta observá-los. Isso se deve à natureza iterativa desses tipos de simulações e à necessidade de encontrar convergência. É melhor visualizado não por uma barra de progresso, mas por um gráfico de iteração v convergência.

Simulações complexas - escrevi um programa que simula um ambiente complexo com muitos fatores relacionados. Era para uma linha do tempo fixa, então a barra de progresso poderia ser a hora certa? No meu caso, a simulação é muito mais longa a cada nova etapa, significando que a barra de progresso fica cada vez mais lenta - não é ótima. Encontrei outra métrica para quanto tempo a simulação média demora, com base no número de itens mais próximos da precisão - mas não é ideal, pois às vezes a barra de processo nunca é preenchida (a simulação parou antes) ou chega a 100% mais cedo (a simulação foi executada) mais do que o esperado).

Em ambos os casos, uma barra completa de progresso puro seria impossível calcular o máximo de antemão (caso 1) ou nenhum linear e, portanto, pouco uso (caso 2)

Ambos. Às vezes, é apenas difícil estimar quanto tempo uma operação levará, porque você não sabe com antecedência quanto trabalho precisa ser feito. Às vezes, suas estimativas simplistas e imprecisas.

Exemplo: estou baixando quatro arquivos simultaneamente. Alguém sabe o tamanho de cada arquivo, quanto foi baixado e quantos megabytes por segundo foram baixados para cada arquivo. Parece fácil prever quanto tempo levará. No entanto, eu sei que depois que um arquivo é baixado, os outros baixam mais rapidamente. Ainda mais após o download de 3 arquivos; o último será baixado quatro vezes mais rápido. Nunca vi nenhuma barra de progresso levando isso em consideração.

Exemplo: você está copiando uma pasta grande. A barra de progresso pressupõe que você copia X megabytes por segundo, sabe quantos megabytes existem e sua velocidade média até o momento. O problema é que "megabytes por segundo" é muito impreciso - na prática, leva x milissegundos por arquivo, mais y milissegundos por megabyte. Portanto, muitos arquivos pequenos levam muito mais tempo do que a barra de progresso antecipa.

O problema é que os desenvolvedores de software podem se importar, mas os gerentes não o fazem desde que o computador não funcione.

Acho que a resposta geral é que muitas vezes é muito complexo (ou impossível) calcular a quantidade de tempo que levará.

Às vezes, seria apenas uma questão de reduzir mais tempo de computação para estimar melhor a quantidade de trabalho necessária (por exemplo, fazer uma análise melhor dos arquivos a serem copiados ou aplicar um cálculo mais complexo para estimar melhor o número de etapas necessárias para complete uma simulação).

Outras vezes, é bastante indeterminado. Quando o sistema está instalando um novo programa, muitas vezes há muitas dependências para verificar se estão instaladas. E, geralmente, não se tem idéia de quanto tempo cada um levará e de quais dependências esses por sua vez precisam. Você já pode ter todas as dependências instaladas e isso pode levar 30 segundos, ou pode estar faltando dezenas e isso leva horas. Difícil dar uma estimativa justa disso, especialmente quando cada situação será única.

Além disso, outros drenos no sistema podem sofrer alterações ao longo do tempo (devido ao que o usuário faz ... ou processos em segundo plano / agendados).

Às vezes, a estimativa poderia ser melhorada se o programador colocasse um pouco mais de trabalho neles. Mas é outra realidade que essa provavelmente não é a principal preocupação dos desenvolvedores, em comparação com o avanço das tarefas produtivas reais que o aplicativo pode realizar.

No final, no momento, acredito que muitas vezes é apenas uma estimativa linear - uma olhada em quantas tarefas básicas necessárias o programa foi concluído. Portanto, de fato tende a ser uma estimativa muito aproximada, e você geralmente deve considerá-la como tal.

---

Uma boa analogia pode ser quando você está lendo um livro.
E você decide que quer ter uma idéia de quanto tempo levará para terminar o livro ...
Você pode verificar a contagem de páginas e obter uma estimativa rápida com base no ritmo até agora.
Pode ser uma estimativa ruim se você acabou de começar a ler, porque sua velocidade talvez ainda não seja típica. Mas muitas vezes seria um palpite bastante difícil.
Ou você também pode folhear o livro, ter uma idéia aproximada de quantas fotos existem e o espaçamento do texto. E então tenha uma idéia melhor do que você enfrenta.
Mas ainda pode ser uma estimativa ruim se, por exemplo, a legibilidade do texto diminuir, talvez passando da prosa simples para a prosa complexa. Ou a estimativa pode acabar errada, porque você não conseguiu prever outra tarefa que desviaria sua atenção.
Você pode obter uma ótima estimativa aplicando uma grande parte do tempo para analisar cuidadosamente o que resta no livro, página por página, e também pode aprimorá-lo verificando seu calendário e mantendo uma lista de ritmos de leitura anteriores de longo prazo para vários livros.
Mas, no final, o tempo que leva para fazer isso vale o atraso em apenas ler o livro?

---

Todos gostaríamos de melhores indicadores. Mas, como é, provavelmente teremos de nos valer de estimativas aproximadas, pelo menos até que os computadores como um todo comecem a obter algoritmos padronizados aprimorados e a serem adeptos a "inteligentemente" pesar e antecipar fatores dinâmicos (como os seus caminhos)!

E a barra de progresso nisso talvez esteja presa a 5% no momento. Vamos ter que ver como isso vai 8-)

Eu acrescentaria à resposta do @ gnasher729 que essa é outra consequência oculta da indecidibilidade do problema da parada.

Deixando de lado a imprevisibilidade inerente dos cálculos interativos, mesmo aqueles que podem ser isolados podem ter um tempo de execução (e "ritmo"), cuja previsibilidade não pode ser abordada por um método geral.

Infelizmente, uma barra de progresso costuma ser uma metáfora inútil. Quais seriam as alternativas, você pode perguntar. Se o usuário estiver ciente do que está acontecendo "oculto", adicionar algumas informações semânticas à interface pode ser uma opção, fazendo a transição para uma execução semelhante ao modo de rastreamento. Caso contrário, crie uma atmosfera calma que reduz as expectativas.

Educar o usuário a entender nossas limitações é uma terceira opção a longo prazo.

As barras de progresso são desenhadas com base no número de subtarefas concluídas, e não no tempo decorrido / necessário para a conclusão.

Por exemplo, suponha que uma operação X tenha quatro sub etapas diferentes, ao final de cada etapa, você aumenta a barra de progresso em 25%. Se uma etapa demorar mais para ser executada, você provavelmente verá o comportamento que descreveu - 1 a 90% de uma vez e horas para o resto.

A lógica por trás do uso do número de subtarefas como uma unidade em vez do tempo é que a última é imprevisível. Mesmo no caso de baixar um arquivo, a conexão pode cair, portanto, o tempo não pode ser usado como uma unidade. Você prefere usar a quantidade de bytes baixados e não o tempo necessário como unidade de progresso.