Jump to content

Recommended Posts

Posted
Citação

[...]

Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”:

Citação

@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days 🙂

You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.

[...]

Artigo longo e interessante sobre o estado do desenvolvimento de software hoje em dia.

Versão completa disponível aqui: http://tonsky.me/blog/disenchantment/

  • Vote 1
Posted

Há muitos anos que eu digo que o PC de teste de um programador deveria ser um chaço arcaico.
Só assim para alguns programadores perceberem que, independentemente de tudo o resto, o programa deveria ser o mais eficiente possível, e dever-se-ia apostar em fazer o melhor possível logo à primeira, para evitar depois a 'perca de tempo' a refactorar.

  • Vote 2

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Posted
2 hours ago, nunopicado said:

Há muitos anos que eu digo que o PC de teste de um programador deveria ser um chaço arcaico.
Só assim para alguns programadores perceberem que, independentemente de tudo o resto, o programa deveria ser o mais eficiente possível, e dever-se-ia apostar em fazer o melhor possível logo à primeira, para evitar depois a 'perca de tempo' a refactorar.

Não concordo totalmente com essa visão.

EU só otimizo quando tenho de otimizar. Não vale a pena estar a otimizar uma aplicação para correr em Windows XP com 1GB de RAM se a realidade é correr em Windows 7 com 4GB de RAM. Isso é tentar resolver um problema que não existe.
A última vez que tive de me "empenhar a sério" nesse tipo de guerra foi quando fiz uma app para Android há alguns anos atrás e como se pretendia que abrangesse o maior número de dispositivos Android possíveis tive de otimizar bastante a aplicação para correr em Android com pouquíssimos recursos.
Já na altura achei que se calhar não fazia grande sentido porque a velocidade com que esses dispositivos são descartados é muito rápida, e na verdade uns 6 meses depois, todo o trabalho adicional foi quase inglório.

Atenção que isto não quer dizer que não se tenha atenção a fazer as coisas como deve ser logo de inicio, apenas estou a dizer que só me preocupo com problemas de performance se, em ambiente de qualificação e/ou produção, tiver problemas de performance.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Posted

Acho que é de dividir o que é software que se sabe à partida onde vai correr e o que não se sabe, e em que condições ele vai correr.

Se faço um software para correr uma vez, admito que também não me preocupo em demasia.
Mas se faço um software que vai correr não sei em que PCs durante não sei quantas vezes e em quanto tempo... Convém ter cuidado com o que se faz.

Lógico que não estou a dizer que temos de entrar em paranóia com isso. Mas uma gestão de memória consciente, com noção mínima do que uma acção implica a nível de performance não é de descartar.

Se o fiz sempre? Não, infelizmente. Hoje olho para os programas em que não o fiz e, mesmo que os PCs sejam agora mais rápidos e portanto ainda se note menos o problema, gostaria de os ter feito correctamente de início, porque sei que cedo ou tarde, havendo tempo, vai-me dar comichão olhar para lá e vou refazer esses programas, mesmo que sem benefício para o utilizador, simplesmente por ficar melhor comigo próprio ao olhar para o código. 😁

  • Vote 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Posted

Acho que o @nunopicado toca em dois pontos fundamentais:

  • É habitual não controlarmos devidamente o ambiente de execução (quer as características do sistema, quer os restantes processos a correr no sistema);
  • Se por acaso existir alguma modificação das circunstâncias que torne a performance um problema, pode ser complicado optimizar a aplicação nesse ponto.

Depois uma coisa é não nos preocuparmos com a performance mas sabermos escrever código minimamente eficiente de raiz.  Outra coisa é literalmente não querer saber da performance e vir com a história de comprar hardware novo.  E esta parece ser a norma hoje em dia.  Já passamos a fase do "optimizar prematuramente é mau", para o "performance não interessa".  Diria também que não estamos a falar de um potencial futuro problema, mas de um problema que efectivamente já é bem visível no software.

  • Vote 2
Posted

Acho que esta questão tem duas vertentes:

- Comercial - Quem tem um projecto de desenvolvimento para executar num dado orçamento irá procurar tudo para reduzir custos directos. Como já foi escrito, o gestor paga o tempo de programação mas não o tempo de execução. Logo a eficiência do código, a menos que seja um critério definido, será sempre uma preocupação secundária.

- Profissional - A larga maioria dos jovens programadores nunca teve de se preocupar com performance na execução do código, apenas com performance na criação do mesmo. De maneira geral, apenas programadores que começaram a desenvolver em máquinas limitadas tiveram de se preocupar com isso. Ferramentas como 'profilers' basicamente caíram em desuso e nem sei se serão referidas em cursos superiores da área. O enfoque que se dá hoje em dia a linguagens como Java e Python como formação primária não ajuda a criar uma mentalidade de eficiência na execução, quando são linguagens que usam 'garbage collection', tirando assim do controlo do programador a maior fonte de ineficiências de código minimamente bem criado, que é a gestão de memória.

Quando ambos se combinam temos todo o tipo de 'bloatware' existente actualmente. Um 'Office Word' actual precisa de mais memória e capacidade de processamento para correr do que a disponível num super-computador Cray X-MP de 1982, ano em que surgiu o IBM PC.

Apenas num mundo em que questões como a eficiência energética (sistemas que têm de funcionar à velocidade máxima, com consumo máximo, devido à carga exercida pela execução de código ineficiente) e o tratamento do lixo electrónico (sistemas deitados fora porque já não conseguem executar adequadamente as novas versões do velho 'software' usado) se tornem importantes levará a uma mudança de prioridades. Mas temo que a 'IA' (aspas usadas depreciativamente) apareça primeiro e tire completamente de mãos humanas a criação da maioria do código.

  • Vote 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.