Benchmark de Tipos de Variáveis

Atualizado em 12/07/17!

Todo mundo aprende, quando inicia os estudos em desenvolvimento de software, que existem os tipos de variáveis. Se você quer que uma variável armazene um número inteiro, você deve declará-la como sendo do tipo Inteiro (Int32, int, Integer, que seja). Se você quer que sua variável contenha um nome, você deve declará-la como uma cadeia de caracteres (string, char[], etc).

Até aí tudo bem e extremamente óbvio (ou nem tanto para os programadores que não usam linguagens fortemente tipadas como JavaScript…), mas e quando complicamos a situação, descobrindo que com diferentes tipos de variáveis obtemos resultados aparentemente iguais?

Ou, porque diabos existe em diversas linguagens o float, o double e o decimal?

Ou o short, o int e o long?

Quando devo usar este ou aquele tipo para determinada variável?

O que acontece se usar o tipo errado?

Estas e outras dúvidas serão discutidas no decorrer do post.

Este post é básico e nem um pouco purista no que tange o domínio de algoritmos realmente eficientes. Apenas quero mostrar como utilizar os tipos de variáveis certas e o impacto disso no desempenho do código final.

Neste artigo você vai ver:

Entendendo os Tipos e os cálculos

Tipos de Variáveis são as estruturas de dados mais elementares da computação.

Sim, isso mesmo.

Um char unicode (caso do C#) nada mais é do que 2 bytes na memória do computador. Uma string é um ponteiro para a primeira posição de uma cadeia de chars em sequência, terminando em um char ‘/0’, indicando final da string. Um inteiro é uma cadeia de 4 bytes (32-bit na maioria das linguagens) permitindo número de aproximadamente -2.1B até +2.1B.

Nada além de estruturas de dados. Agora imagine você o custo que existe para o processador de armazenar e calcular milhões de vezes estas estruturas nos algoritmos que você desenvolve. Qualquer um que ignore estes conhecimentos com certeza não está desenvolvendo software otimizado e mais cedo ou mais tarde terá gargalos de performance em suas aplicações.

Os testes mais à frente mostrarão do que estou falando.

Mas voltando ao que interessa, cada um dos tipos existem para um propósito. Enquanto que alguns apenas provêem formas mais simples de manipular valores complexos (como Strings) outros fazem parte da essência da arquitetura do processador.

O uso incorreto de tipos faz com que o processador tenha de efetuar operações desnecessárias, como LOAD, STORE e outras operações Assembly que nunca conseguiremos escapar. No centro do processador existe a ULA, ou Unidade Lógico Aritmética, um “circuito” capaz de fazer apenas uma operação, a soma. A soma é a operação elementar e com base nela conseguimos fazer qualquer outra operação existente. Uma subtração nada mais é do que uma soma entre um número positivo e outro negativo. Uma multiplicação nada mais é do que somas consecutivas. E por aí vai. Ou seja, a soma é a operação que menos exige do processador.

Assim como a soma é a operação elementar, o inteiro é o tipo de dado elementar, pois ele é construído com o tamanho padrão de palavras da arquitetura 32-bits, que até poucos anos atrás era a mais comum em processadores. Resumindo: a soma entre inteiros é o cálculo de maior desempenho e menor custo a um processador.

Quando manipulamos variáveis de outros tipos, aumentamos proporcionalmente a complexidade do cálculo e o número de ciclos que o processador levará para executá-lo. Quanto mais complexa a estrutura, mais tempo levará para ser calculada.

Ok, devo estar parecendo um programador C falando, mas é a mais pura verdade e uma das coisas que mais respeito nos programadores C é seu apreço pelo uso correto da linguagem de programação. E sim, eu já fui programador C um dia, em meados de 2007. 🙂

Entendendo o funcionamentos dos Tipos

O pessoal que trabalha com Internet adora falar de semântica web certo? Mas eles costumam se esquecer de algo muito mais importante quando o assunto são os SISTEMAS web: a semântica dos tipos de variáveis.

Renderização de páginas HTML por browsers é algo feito no lado do cliente, ou seja, de forma distribuída e independente do servidor. Já a lógica do sistema é feita toda no servidor (de todas as requisições dos usuários), onde está realmente o gargalo de tempo, onde está a lógica do negócio, é muitas vezes relegado à segundo plano nos projetos web e mobile modernos.

Então vamos falar de algo que me interessa mais do que porque devemos usar DIVs e não TABLEs: semântica de tipos. Primeiramente uma pequena lista dos tipos de variáveis do C# e uma rápida explicação de seu funcionamento e/ou capacidade (no Java e outras linguagens não muda muito):

  • int ou Int32 = números inteiros de 32 bit (indo de -2.1B a +2.1B)
  • short ou Int16 = números inteiros de 16 bit (indo de -32.500 a +32.500 aproximadamente)
  • long ou Int64 = números inteiros de 64-bit (-9 quinquilhões até +9 quinquilhões)
  • byte = números inteiros de 0 a 255 (8-bit sem sinal)
  • char = apenas um caractere unicode, ocupando 16-bit (diferente do C, onde ocupa apenas 4-bit por ser ASCII)
  • string = um ponteiro apontando para a primeira posição de uma cadeia de caracteres, terminando em ‘/0’
  • float ou Single = um número com ponto flutuante de 32-bit com baixa precisão
  • double = um número com ponto flutuante de 64-bit com média precisão (precisão dupla em relação ao float)
  • decimal = um número com ponto flutuante de 128-bit com alta precisão, mas com um intervalo inteiro curto (digamos que tem mais casas depois da vírgula do que antes dela)

Ninguém duvida que sempre que queremos declarar variáveis que armazenarão números inteiros devemos usar o tipo int certo?

Mas e porque existem tantos outros tipos de números inteiros então?

Apenas uma resposta: necessidade. Os inteiros são eficientes pois possuem o tamanho exato para serem somados em apenas um ciclo de processamento com outro inteiro. Mas isto os limita a 32-bit de valores possíveis (4.5B aproximadamente).

E quando precisamos mais do que 5B de opções?

Aí que entra, por exemplo, o long. Inteiros longos somente devem ser usados quando o intervalo de números de um inteiro não atende às necessidades da aplicação.

E o short?

À primeira vista você deve pensar que inteiros curtos servem para os cálculos serem realizados mais rápidos certo?

Errado.

O cálculo de operações sobre inteiros curtos leva o mesmo tempo do que os inteiros comuns, pois nada demora menos do que um ciclo de processamento, mesmo que ocupe meia-palavra na arquitetura do processador (atualmente até os inteiros comuns ocupam meia-palavra por causa dos processadores 64-bit).

Então para que serve o short?

Economia de memória.

Shorts ocupam apenas 16-bit de memória, o que faz com que consumam metade do que um inteiro consumiria e isto é muito útil considerando o custo de memória atual, principalmente a memória cache dos processadores, ainda assim, não produzem, mesmo na casa das milhões de operações, alguma diferença a ser considerada (os exemplos mais à frente mostrarão isso também). Ou seja, não se preocupe com shorts e ints, a menos que o recurso de memória seja algo crítico em sua aplicação.

O byte por sua vez não foi criado para armazenar números pequenos entre 0 e 255. Bytes são usados, geralmente em arrays, para representar cadeias binárias, como streams, imagens bufferizadas e por aí vai. Simplesmente não vale a pena usá-lo se não for para realmente representar bytes. Se alguém quiser fazer um benchmark sobre o uso de bytes vs inteiros e me mostrar do contrário, eu atualizo o post, mas até o momento não tenho provas do contrário.

Quando entramos nos números com ponto flutuante é que pegamos no “calcanhar de Aquiles” dos processadores.

Operações com ponto flutuante, até mesmo a soma, a mais elementar de todas, é onde o bicho pega e o desempenho da aplicação cai drasticamente. É aqui que todo engenheiro de software que se preze deveria colocar sua atenção e evitar bobagens como doubles no lugar de floats ou floats no lugar de inteiros.

Operações com ponto flutuante são tão custosas para os processadores que existe uma unidade de medida de capacidade de processamento chamada de GFLOP, ou GigaFlops. Esta unidade é muito utilizada em computação pesada como placas de vídeo e super-processadores (incluindo as GPUs de videogames). A quantidade de GFLOPs de um processador indica quantos bilhões de operações com ponto flutuante o processador pode executar por segundo. E embora uma valor de 1GFLOP possa parecer mais do que você precisa, lembre-se que o processador nunca está apenas processando o SEU algoritmo.

O float está para os números com ponto assim como o inteiro está para os números sem ponto. Ou seja, se você tem certeza que necessita armazenar as casas decimais da sua variável e não necessita de grande precisão, use o float.

Isto por si só já terá um impacto de 20% mais ciclos nas somas elementares, mesmo que a soma seja entre um float e um int.

Sim, uma vez que você coloca um float em uma expressão aritmética, todos os demais números da expressão serão “formatados” como se fossem floats para que o cálculo possa ser completado. Lembre-se das somas da primeira série quando temos um número de uma casa sendo somado com outro de duas. O número menor terá zeros colocados à esquerda. É a mesma coisa com o float e por mais que uma soma com zero pareça inofensiva, ela consome ciclos. No caso dos floats, muitos ciclos pois os zeros também existirão à direita…

O double é utilizado na mesma ocasião que o long + os problemas do float. Ou seja, intervalos superiores a 2.5B + uma precisão decimal muito boa. Imagine o estrago que isso causa nos cálculos! Apesar disso, nossas arquiteturas atuais operam muito bem com longs e doubles devido à sua natureza de 64-bit, elevando apenas um pouco mais do que o normal o tempo de execução de tais cálculos. Ainda assim, evite sempre que puder.

O decimal é utilizado quando precisamos de extrema precisão depois da vírgula. Isso porque o float tradicional tem uma maneira bem peculiar de armazenar os números decimais dentro dele que faz com que tenha pouca precisão. Isso fica mais evidente quando salvamos floats simples como 1.9 no banco de dados e depois fazemos uma consulta e nos deparamos com algo como 1.899999. Estranho não?

Isso se resolve facilmente usando um decimal, que é um tipo que permite poucas casas antes da vírgula mas muitas depois, com uma precisão e fidelidade muito boas. O benchmark a seguir mostrará que o decimal possui um gargalo gigante de processamento, o que o torna mal visto em testes de performance e seu uso não é lá muito recomendado, exceto se necessário.

Uma outra ideia para quem quer evitar os decimais é usar Int. Sim, isso mesmo. Todo valor monetário é um número inteiro expresso em centavos. Assim, R$10,00 nada mais é do que 1000 centavos. Na hora de exibir na tela, você terá o mesmo trabalho que teria com o float, usar um simples String.Format. Pense nisso.

Não tenho muitas considerações sobre caracteres e strings.

Strings são um mal necessário e mesmo que o pessoal do C se gabe de não usá-las, lembrem-se que ponteiros de caracterer (char*) nada mais são do que strings enrustidas, hehehehehe. Antes que me crucifiquem-me por não falar dos gargalos de performance de strings, lembrem-se que todo e qualquer cálculo sobre strings (Replaces, por exemplo) são custosos. Já debati um pouco a respeito no Benchmark de Expressões Regulares e mais pra frente quero fazer um post sobre Benchmark de Strings, mas por ora, usem a premissa básica de que se você tem uma palavra, o mais sensato é usar String. Se tem caracteres individuais, use char.

Here we go!

Criei uma aplicação console simples com .NET Core que mostra o tempo de processamento de operações simples sobre os tipos de variáveis mais comuns de serem encontrados em aplicações.

A aplicação se divide em duas partes, a soma e a multiplicação. Enquanto que na soma a diferença de manipulação dos tipos é mínima, quando efetuamos multiplicações isso aumenta um pouco nos tipos inteiros e bastante nos com ponto flutuante.

Nestes testes é possível ver, também, que inteiros curtos não têm ganho sobre inteiros comuns.

Note também que na multiplicação foi utilizado um número com ponto flutuante para os tipos flutuantes, por dois motivos: primeiro, para não estourar o limite das variáveis antes da bilionésima iteração do laço e segundo: para mostrar o gargalo que são as operações com ponto flutuante.

Os testes foram feitos em um Macbook Pro Mid-2009 rodando Mac OS X 64-bit com um Core 2 Duo 2.2GHz e 8GB RAM, com o .NET Core 1.1 instalado.

Resultado da soma de variáveis

Os resultados foram muito próximos, com exceção do decimal. Da soma de inteiros para as demais somas, temos uma diferença de aproximadamente 1 segundo a mais, uma vez que meu processador e sistema operacional são 64-bit e lidam com longs e doubles com a mesma facilidade que ints.

Vale atenção ao short que como é um tipo com capacidade muito pequena, conforme vamos incrementando e sua capacidade estoura, ele “dá a volta” começando a usar os números negativos também. Se apenas somarmos até o short chegar no seu limite, seu tempo é menor que 1ms pois chega a pouco mais de 32k positivo no máximo.

No entanto a soma entre decimais (mesmo que usando apenas números inteiros) leva aproximadamente 10 vezes mais tempo do que com os demais tipos, como mostra no gráfico abaixo construído após meus testes.

Resultados da Soma
Resultados da Soma

Note que apesar de visualmente a maioria dos tipos não apresentar grande diferença, saliento que ela chega a 25% do menor para o maior tipo (excluindo o decimal da comparação que é obviamente lento no gráfico). Esses 25% podem fazer bastante diferença dependendo do seu sistema.

Os fontes estão abaixo:

Subtrações, que são apenas somas com sinal negativo, devem ter a mesma performance. Mas e quando usamos outras operações?

É o que veremos a seguir…

Resultado da multiplicação de variáveis

Quando entramos no campo das multiplicações, eu tive de adicionar números com ponto flutuante para as variáveis de tipos flutuantes, para que o cálculo fosse aumentando o tamanho do número inicial em uma pequena % a cada iteração, evitando estourá-lo muito rápido, principalmente o decimal.

Para os números sem casas decimais, dobramos eles 1B de vezes. Para os números com casas decimais incrementamos em 10% 1B de vezes, com exceção do decimal.

Benchmark Multiplicação
Benchmark Multiplicação

Neste cenário floats e double possuem quase o mesmo desempenho, que é bem proporcional ao de tempo dos cálculos com inteiros (menos de 500ms de diferença). No entanto, da execução mais rápida à mais lenta, temos 25% de diferença também. Já o decimal é quase 40x mais lento que os demais para efetuar 1B multiplicações e você já deve ter sacado que não é uma boa ideia usar ele em sistemas que exijam grande processamento de requisições.

Para divisões, que nada mais são do que multiplicações com frações, o desempenho deve se mostrar o mesmo.

Os fontes desse segundo teste podem ser conferido abaixo:

Conclusões

Espero que tenham gostado do post e que tenha sido de alguma utilidade para vocês desenvolvedores. Nós cientistas da computação muitas vezes temos problemas complexos para solucionar e muitas vezes caímos no “achismo” ao invés de utilizarmos a experimentação científica, que seria a maneira correta de levantar evidências que comprovem nossas opiniões.

Enquanto que alguns subestimam a instrução formal e o estudo das Ciências da Computação, é no “frigir dos ovos” e nos verdadeiros embates de conhecimento que vemos a diferença entre desenvolvedores de sistemas e digitadores de código.

Obviamente não consegui explanar aqui tudo que se pode aprender sobre tipos de variáveis e usei exemplos mais práticos do que teóricos. Outros estudos neste campo incluem a documentação da linguagem C# presente no MSDN, o estudo da precisão dos pontos-flutuantes, o estudo dos valores inteiros e dos valores decimais.

Também não falei sobre os unsigned types (tipos sem sinal) que aproveitam o bit que é utilizado para armazenar o sinal (+ ou -) da variável para obter o dobro de números possíveis de serem armazenados. Futuramente quero dedicar um post único sobre desempenho de Strings.

Até a próxima!

As Leis de Murphy

Murphy é figura tarimbada dentro da informática com suas leis incontestáveis, acima até mesmo das leis de Newton e outros físicos famosos. Como o pessoal fora do círculo tecnológico (para não dizer nerd) costuma não conhecer as leis de Murphy, reproduzo algumas de suas famosas leis abaixo, para conhecimento geral.

1. Um atalho é sempre a distância mais longa entre dois pontos.
2. A beleza está à flor da pele, mas a feiúra vai até o osso!
3. Nada é tão fácil quanto parece, nem tão difícil quanto a explicação do manual.
4. Tudo leva mais tempo do que todo o tempo que você tem disponível.
5. Se há possibilidade de várias coisas darem errado, todas darão – ou a que causar mais prejuízo.
6. Se você perceber que uma coisa pode dar errada de 4 maneiras e conseguir driblá-las, uma quinta surgirá do nada.
7. Seja qual for o resultado, haverá sempre alguém para: a) interpretá-lo mal. b) falsificá-lo. c) dizer que já tinha previsto tudo em seu último relatório.
8. Quando um trabalho é mal feito, qualquer tentativa de melhorá-lo piora.
9. Acontecimentos infelizes sempre ocorrem em série.
10. Toda vez que se menciona alguma coisa: se é bom, acaba; se é mal, acontece.
11. Em qualquer fórmula, as constantes (especialmente as registradas nos manuais de engenharia) deverão ser consideradas variáveis.
12. As peças que exigem maior manutenção ficarão no local mais inacessível do aparelho.
13. Se você tem alguma coisa há muito tempo, pode jogar fora. Se você joga fora alguma coisa que tem há muito tempo, vai precisar dela logo, logo…
14. O modo mais rápido de se encontrar uma coisa é procurar outra. Você sempre encontra aquilo que não está procurando.
15. Quando te ligam:
– se você tem caneta não tem papel.
– se tem papel não tem caneta.
– se tem ambos ninguém liga.
16. Não se chateie se a programação da TV lhe parece chata: amanhã será pior.
17. Entre dois acontecimentos prováveis, sempre acontece um improvável.
18. Quase tudo é mais fácil de enfiar do que de tirar.
19. Mesmo o objeto mais inanimado tem movimento suficiente para ficar na sua frente e provocar uma canelada.
20. Qualquer esforço para se agarrar um objeto em queda provocará mais destruição do que se deixássemos o objeto cair naturalmente.
21. A única falta que o juiz de futebol apita com absoluta certeza é aquela em que ele está absolutamente errado.
22. Por mais bem feito que seja o seu trabalho, o patrão sempre achará onde riscá-lo.
23. Nenhum patrão mantém um empregado que está certo o tempo todo.
24. Adiar é a forma mais perfeita de negar.
25. Quando político fala em corrupção, os verbos são sempre usados no passado.
26. Se você for esperar o motivo certo para fazer alguma coisa, nunca fará nada.
27. Os assuntos mais simples são aqueles que você não entende nada.
28. Dois monólogos não fazem um diálogo.
29. Se você é capaz de distinguir entre o bom e o mal conselho, você não precisa de conselho.
30. Toda a idéia revolucionária provoca três estágios: 1º. ‘é impossível – não perca meu tempo.’ 2º. ‘é possível, mas não vale o esforço’ 3º. ‘eu sempre disse que era uma boa idéia’
31. A informação que obriga a uma mudança radical no projeto sempre chega ao projetista depois do trabalho terminado, executado e funcionando maravilhosamente (também conhecida como síndrome do: “P****! Mas só agora!!!”).
32. Um homem com um relógio sabe a hora certa. Um homem com dois relógios sabe apenas a média.
33. Só sabe a profundidade da poça quem cai nela.
34. Nada é impossível para quem não tem que fazer o trabalho.
35.Se há um trabalho difícil de ser feito, entregue-o a um preguiçoso. Ele descobrirá a maneira mais fácil de fazê-lo.
36. Quando se tem muito tempo para começar um trabalho, o primeiro esforço é mínimo. Quando o tempo se reduz a zero, o esforço beira as raias do infinito.
37. Nada jamais é executado dentro do prazo ou do orçamento.
38. As variáveis variam menos que as constantes.
39. Não é possível alcançar o total exato de qualquer soma com mais de dez parcelas depois das cinco horas da tarde de sexta feira. O total exato será encontrado facilmente as 9:01 da manhã de segunda feira.
40. Entregas de caminhão que normalmente levam um dia levarão cinco quando você depender da entrega.
41. Depois de acrescentar ao cronograma duas semanas paras atrasos imprevisíveis, acrescente mais duas para atrasos previsíveis.
42. Assim que tiver esgotado todas as suas possibilidades e confessado seu fracasso, haverá uma solução simples e óbvia, claramente visível a qualquer outro idiota.
43. Qualquer programa quando começa a funcionar já está obsoleto.
44. Qualquer upgrade custa mais e leva mais tempo para aprender.
45. Só quando um programa já está sendo usado há seis meses, é que se descobre um erro fundamental.
46. Depois da linguagem cibernética, a linguagem mais falada pelos programadores é a obscena.
47. A ferramenta quando cai no chão sempre rola para o canto mais inacessível do aposento. A caminho do canto, a ferramenta acerta primeiro o seu dedão.
48. Só um idiota tem talento típico para plagiar outro idiota.
49. Guia prático para a ciência moderna:
– Se se mexe, pertence à biologia.
– Se fede, pertence à química.
– Se não funciona, pertence à física.
– Se ninguém entende, é matemática.
– Se não faz sentido, é economia ou psicologia.
50. A diferença entre as leis de Murphy e as leis da natureza é que na natureza as coisas dão erradas sempre do mesmo jeito.
51. O número de exceções sempre ultrapassa o numero de regras. E há sempre exceções às exceções já estabelecidas.
52. Ninguém nunca está ouvindo, até você cometer um erro.
53. Qualquer coisa entre parênteses pode ser ignorada (com vantagem, como vê neste exemplo perfeitamente inútil).
54. Se o curso que você desejava fazer só tem “n” vagas, pode ter certeza de que você será o candidato “n + 1? a tentar se matricular.
55. Oitenta por cento do exame final da sua prova da faculdade será baseada na única aula que você perdeu, baseada no único livro que você não leu.
56. Cada professor parte do pressuposto de que você não tem mais o que fazer, senão estudar a matéria dele.
57. A citação mais valiosa para a sua redação será aquela em que você não consegue lembrar o nome do autor.
58. Não há melhor momento do que hoje para deixar para amanhã o que você não vai fazer nunca.
59. A maioria dos trabalhos manuais exigem três mãos para serem executados.
60. As porcas que sobraram de um trabalho nunca se encaixam nos parafusos que também sobraram.
61. Quanto mais cuidadosamente você planejar um trabalho, maior será sua confusão mental quando algo der errado.
62. Os pontos de acesso a uma máquina serão sempre pequenos demais para a passagem das ferramentas, ou grandes para passagem delas, mas não suficiente para a passagem de sua mão quando elas caírem.
63. Em qualquer circuito eletrônico, o componente de vida mais curta será instalado no lugar de mais difícil acesso.
64. Qualquer desenho de circuito eletrônico deve conter pelo menos uma peça obsoleta, duas impossíveis de encontrar, e três ainda sendo testadas (por você, é claro).
65. Na última hora o engenheiro industrial mudará os desenhos originais para incluir novos defeitos. E as modificações não serão mencionadas no manual de instruções, já impresso.
66. O tempo para executar uma tarefa é 3 vezes superior ao tempo inicialmente previsto. Se, ao calcular a duração da tarefa, multiplicarmos por 3 o tempo previsto de modo a obter o resultado correto, nesse caso, a tarefa demorará 9 vezes esse tempo.
67. Uma gravata limpa sempre atrai a sopa do dia.
68. Se está escrito “Tamanho único”, é porque não serve em ninguém.
69. Nunca há horas suficientes em um dia, mas sempre há muitos dias antes do sábado.
70. Todo corpo mergulhado numa banheira faz tocar o telefone.
71. Se alguma coisa pode dar errado, dará. E mais, dará errado da pior maneira, no pior momento e de modo que cause o maior dano possível.
72. A informação mais necessária é sempre a menos disponível.
73. A probabilidade do pão cair com o lado da manteiga virado para baixo é proporcional ao valor do carpete.
74. A fila do lado sempre anda mais rápido.
75. As coisas podem piorar, você é que não tem imaginação.
76. O material é danificado segundo a proporção direta do seu valor.
77. Se você está se sentindo bem, não se preocupe. Isso passa.
78. Lei de Murphy no ciclismo: não importa para onde você vai; é sempre morro acima e contra o vento.
79. Por mais tomadas que se tenham em casa, os móveis estão sempre na frente.
80. Existem dois tipos de esparadrapo: o que não gruda, e o que não sai.
81. Uma pessoa saudável é aquela que não foi suficientemente examinada.
82. Por que será que números errados nunca estão ocupados?
83. Se você não está confuso, não está prestando atenção.
84. Na guerra, o inimigo ataca em duas ocasiões: quando ele está preparado, e quando você não está.
85. Amigos vêm e se vão, inimigos se acumulam.
86. A Lei de Murphy é algo transcendente. Lavar o seu carro para fazer com que chova não funciona.
87. Um documento importante irá demonstrar sua importância quando, espontaneamente, ele se mover do lugar que você o deixou para o lugar onde você não irá encontrá-lo.
88. As crianças são incríveis. Em geral, elas repetem palavra por palavra aquilo que você não deveria ter dito.
89. Uma maneira de se parar um cavalo de corrida é apostar nele.
90.Toda partícula que voa sempre encontra um olho.

Grátis: O Futuro dos Preços – Resenha

Para quebrar um pouco meus posts sobre o protocolo OAuth, que embora tenha tomado meu tempo durante um ano inteiro de pesquisas não interessa pra todo mundo, volto a fazer um de meus tradicionais posts com resenhas de livros que acabei de ler e gostei.

O livro que trago hoje já foi comentado em outros posts do blog, sempre que falo em modelos de negócio baseados no grátis. Isso porque comprei ele já há algum tempo mas só anteontem que fui terminá-lo. Agora estou lendo o ótimo Efeito Facebook, de David Kirkpatrick, mas esse fica para outro post.

Free

O título original de Grátis: O Futuro dos Preços é simplesmente Free. Precisa mais do que isso?

Não, o livro não é distribuído gratuitamente nas livrarias, mas segundo o autor, o premiado físico e editor Chris Anderson, ele está disponível para download em um PDF em inglês no site dele ou algo do gênero. Como minha preguiça é maior do que minha vontade de ajudar o próximo, dê uma procurada na net que você deve achar. A idéia aqui, como sempre, é falar um pouco do autor, do livro e das minhas conclusões, nem sempre muito conclusivas. Se você já leu, comente depois do post. Se não leu mas se interessou, comente. Se não aguenta me ver pedindo comentários no blog, comente também.

O Autor

Chris Anderson é graduado em Física por uma faculdade estrangeira que não lembro o nome, mas que não é o MIT ou Harvard, se não eu lembraria com certeza. Ele é autor do também best-seller, A Cauda Longa que mostra a trajetória e as tendências do comércio virtual e da própria comercialização na Internet. Não, eu não li A Cauda Longa (The Long Tail no original) mas li algumas resenhas por aí. Chris é editor da revista Wired, e um excelente escritor. Ele é especializado em escrever sobre tecnologia há muitos anos e você fica boquiaberto com os detalhes históricos que ele coloca em seus textos, auxiliando o leitor a compreender os fenômenos sociais e comerciais que ocorreram na Internet com a precisão de um relógio suíço. Ele também é o fundador do TED Talks, aqueles eventos com palestrantes sensacionais que tem os vídeos no Youtube, sabe?

O Livro

Free, vou chamá-lo assim pois é mais curto, trata da evolução dos preços. Desde a época feudal até as sociedades digitais atuais. Ele relata o quanto os bens de consumo oscilam de preço conforme demanda, abundância, escassez, e outros fatores e como a revolução digital que veio com o advento da Internet se aproveitou disso para tornar os preços absurdamente próximos de zero. Ele explica como empresas áreas francesas lucram vendendo passagens aéreas por $30. Como jornais americanos lucram incluindo talheres de prata legítima como brinde. Como o Google ganha milhões com buscas gratuitas na Internet. Como artistas ganham muito dinheiro distribuindo músicas de graça na Internet.

Não se detendo apenas em cases de sucesso, o livro narra os maiores erros cometidos por empresas que tentam utilizar o grátis para atrair clientes e acabam indo à falência. Mostra seus erros, nos faz refletir sobre o que é melhor para cada modelo de negócio. Será que o Grátis funciona 100% das vezes? Como competir com o Grátis? Quais são as modalidades de grátis existentes? Quem é que paga pelo grátis na Internet? Essas e outras dúvidas foram alvo de estudo do sr. Anderson que compilou tudo em um excelente livro, que embora seja um pouco salgado (paguei 70 pilas na época) devia ser lido por qualquer empresa que lide com Internet.

Conclusões

Caro. Sei lá, ele fala muito do grátis mas a editora meteu a faca ao lançar o livro. talvez se o Cauda Longa não tivesse sido tão vendido e o autor não estivesse com a bola toda fosse mais barato. Mas voltando ao que interessa, obviamente eu, um nascido na geração da Internet, um rapaz que não sofreu com Internet discada, que baixa PDFs, MP3s e faz buscas gratuitas no Google desde que se conhece por gente, não me admirei com a maioria das propostas do livro. Obviamente, gerentes de empresas mais tradicionais, ou apenas gerentes que tenham nascido antes da década de 80, provavelmente devem considerar a aquisição desse livro para reverem seus conceitos. A frase vai soar bizarra, mas tem muita empresa deixando de ganhar dinheiro por estar cobrando pelos seus serviços. Ou ao menos cobrando o valor errado.

Dá uma olhada na amostra grátis aí embaixo e tira suas próprias conclusões: