Amazing

Desenhar é tomar decisões. Essa máxima é especialmente verdadeira em software. O engenheiro, em vários momentos, tem que decidir entre opções para projetar um documento de software. Esse documento pode ser a arquitetura do software, ou o código.

Toda vez que uma opçao é escolhida outra opção foi preterida.

Quando pensamos em qualidades a serem preenchidas pelo produto, muitas vezes uma opção por uma caractéristica de qualidade pode levar a que outra caractéristica não seja bem atingida. Quando desejamos fazer um software que economize memória, essa opção certamente implicará em perda de performace.

No caso assinalado nessa nota existe um debate sobre se mais legibilidade em documentos de software pode levar a perda de eficiência. Em particular na construção de documentos passíveis de execução, isto é documentos escritos em linguagens de programação.

Estava preparando uma nota de aula, quando me deparei com a tarefa de buscar exemplos em que fosse claro o impacto entre eficiência e legibilidade de código. Encontrei
dois lugares onde o tema era tratado de alguma forma.

O primeiro é o de um engenheiro de software da Sun na área de jogos. Para esse engenheiro eficiência é fundamental e deve prevalecer em decisões de desenho. No seu “blog” essa opinião está em um artigo que fala sobre revisão de código. Não concordo com esse autor sobre revisão de código,  mas sobre eficiência ele diz:

A)  “Similarly, there is an important rule in performance tuning. What doesn’t matter, doesn’t matter. Anyone who does serious performance coding, and all game programmers do, knows that striving for maximal efficiency across all your code is not just wasteful but often counter productive. The most efficient code is not necessarily the cleanest, clearest or most maintainable. But efficiency in the right places can be critical to over-all program performance. The general rule is called the “90/10″ rule. In general 10% of your code does 90% of the work and it is that 10% that needs to be tuned for efficiency. The rest should be designed for readability and maintainability.” [ref]

B) ” More importantly though, as I’ve already said, I don’t believe that you should make people do things that computers can do just as well and faster. Java has standard naming conventions which is great. Why we don’t have a lint-like tool to check them though is frankly beyond me. This is the sort of job a compiler or compiler-like program can do over hundreds of thousands of lines of code without breaking a sweat.” [ref]

C) “Something that, for similar reasons, I think is even sillier are formatting conventions. The fact of the matter is that readability of formatting conventions is highly subjective. There is no one right answer. The tools exist to reformat code however you like to read it completely on the fly. So rather then trying to push everyone into coding in the same format, just let everyone format the code they want to read however they are most comfortable reading it.” [ref]

Ou seja ,ele faz uma defesa de que, tendo que optar, ele opta pela eficiência. No entanto, um aspecto é importante na sua argumentação: a referência a Regra de Pareto. Como bem explica Steve McConnel em Code Complete, a regra 80/20, ou Regra de Pareto já foi observada por Barry Boehm, por Knuth (4% de um programa é responsável por mais de 50% de seu tempo de execução) e por Bentley (descreve um caso em que um programa de mil linhas gasta 80% de seu tempo numa rotina de raiz quadrada com cinco linhas). Isso leva McConnel a dizer: “não otimize até que você encontre uma razão para tal.”

O outro lugar onde achei um debate interessante é o sítio de Alex Papadimoulis onde ele faz uma crítica severa a um livro escrito por engenheiros da Microsoft. Em particular vejam essa parte:
“Next, the authors focus on “speed and efficiency” as if it’s 1963 and a few CPU hours cost as much as a car. In the world of BILLIONS (1,000,000,000’s) of cycles per second (Ghz), it really is ok to “waste” a few cycles on making sure your code is easier to read and maintain. You wouldn’t get that impression from reading this book as a beginner:
pp 127: “the as operator … speeds up execution”
pp 149: “Return keyword enables the compiler to optimize your code more efficiently.”
pp 251: “language specific functions perform worse”
pp 253: “the ChrW function is faster”
pp 257: “the CompareOrdinal static method … is typically faster”
They did not drive the point of maintainability over speed. 100 clock cycles will make ZERO difference on a 10 millisecond request.”  [ref]. Ou seja porque preocupar-se com eficiência se o hardware custa barato!

O interessante é que um dos autores (Francesco Balena) respondeu a crítica dizendo:
“While on the topic of execution speed: most of the techniques you consider as questionable can make your code run faster by at least 50%, or more. If the offending statement appears in a tight loop they can save you a significant amount of time, not just a few CPU cycles. In a server-side component this sort of optimization makes the difference and can positively affect scalability – I am surprised you missed the point.” [ref]

Concordo, muitas vezes, principalmente se o número de execuções é de grande monta, o que é de pequena escala, por um efeito de grandes números torna-se um número significativo.

Em um dos comentários dessa discussão uma pessoa diz: “Umm, have you ever worked on a website with 15 million members, and an average of 3 million visitors a day, that spend more than 2 hours on average? You see, in situations like that speed is very important. A single try statement, when repeated billions of times, can brake your application.” [ref]. Ou seja quando os números são grandes  o  efeito multiplicador traz surpresas.

This entry was posted on março 11, 2007 at 8:16 pm and is filed under software engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.