Guia para realizar um teste de benchmark de computador significativo para produtividade

Programas de benchmark tentam analisar o “desempenho” de um computador com base em uma base de teste bem definida (normalmente nem perto da configuração final do computador). O responsável pelo benchmark pode tirar vantagem dos limites para confrontar, como recursos do sistema, ambiente de software virtual, aplicativos, simulação de carga de processamento, simulação de carga do usuário e simulação de uso do sistema, entre outros; e fazer o que for necessário para superar esses limites e dar um resultado questionável. Agora, “ter um benchmark padrão da indústria é sempre uma coisa boa, se os benchmarks não forem manipulados. Infelizmente, muitos benchmarks da indústria são manipulados. [...] No entanto, muitas organizações parecem comprar hardware com base em benchmarks em vez de entender suas cargas de trabalho e comprar hardware com base em seus requisitos e, é claro, orçamento.” (Newman, 2015) Isso explica por que o cliente precisa saber exatamente o que se pretende medir. Um programa de benchmark nunca será capaz de refletir a chamada experiência do mundo real; apenas refletirá o quão bem esse programa funciona no computador pretendido. Portanto, é responsabilidade do cliente determinar como o resultado será aplicado em seu ambiente produtivo.

Surpreendentemente, fazer benchmarks corretamente é algo realmente difícil, porque existem muitas possibilidades de trazer resultados ruins ou enganosos e de omitir coisas. O white paper “A Nine Year Study of File System and Storage Benchmarking” resume isso:

Neste artigo, pesquisamos 415 benchmarks de sistema de arquivos e armazenamento de 106 artigos recentes. Descobrimos que a maioria dos benchmarks populares são falhos e muitos artigos de pesquisa não fornecem uma indicação clara do verdadeiro desempenho. (Traeger, Zadok, Joukov, & Wright, 2008)

Nesse white paper, podem ser vistas declarações sobre que os benchmarks devem explicar o que está prestes a ser testado e por quê, e também devem fazer (ou facilitar) uma espécie de análise do desempenho esperado do sistema.

No artigo “Performance Anti-Patterns”, há alguns pontos destacados para determinar, neste caso, para que e como os benchmarks devem ser executados. Portanto, um bom benchmark deve ser:

• Repetível, para que experimentos de comparação possam ser conduzidos de forma relativamente fácil e com um grau razoável de precisão.
• Observável, de modo que, se um desempenho ruim for visto, o desenvolvedor tenha um ponto de partida para procurar. Nada é mais frustrante do que um benchmark complexo que entrega um único número, deixando o desenvolvedor sem informações adicionais sobre onde o problema pode estar.
• Portável, para que comparações sejam possíveis com seus principais concorrentes (mesmo que sejam seus próprios lançamentos anteriores). Manter um histórico do desempenho de lançamentos anteriores é uma ajuda valiosa para entender seu próprio processo de desenvolvimento.
• Facilmente apresentado, para que todos possam entender as comparações em uma breve apresentação.
• Realista, para que as medições reflitam as realidades experimentadas pelo cliente.
• Executável, para que todos os desenvolvedores possam verificar rapidamente os efeitos de suas mudanças. Se levar dias para obter resultados de desempenho, isso não acontecerá com muita frequência.

Nem todos os benchmarks selecionados atenderão a todos esses critérios, mas é importante que alguns deles atendam. Smaalders convida a escolher benchmarks que realmente representem as necessidades do cliente, ou todos os esforços acabarão otimizando para o comportamento errado. Ele também incentiva resistir à tentação de otimizar para o benchmark com o objetivo de vencer o concurso a qualquer preço. Esse comportamento oferecerá resultados falsos que podem trazer falta de confiança na marca ou no fornecedor. Geralmente, um benchmark destacará o aspecto que é otimizado, em detrimento de outros aspectos que não estão sendo medidos (e que podem ser importantes para o cliente). (Smaalders, 2006)

Existe outra coisa ao comparar vários sistemas com a intenção de comprá-los: a taxa de preço/desempenho. Essa taxa pode ser quantificada incluindo o custo de capital de 5 anos do equipamento. (Anon & Gray, 1985)

Testes simples com software de benchmark não compreendem uma análise de desempenho completa. Programas de benchmark normalmente funcionam em um ambiente controlado, portanto podem ser manipulados para obter uma taxa desejada—a mais alta possível. No entanto, essa taxa NUNCA nos dará uma correlação adequada com a experiência real do cliente. Em vez disso, as métricas fornecidas apenas oferecem uma pontuação que é representativa de quão bem ele funciona em um determinado benchmark. Um grande problema é que o usuário nunca sabe realmente o que é testado, como os aspectos da pontuação de um benchmark são medidos, quais sinalizadores (flags) foram definidos no compilador, qual código ou bibliotecas estão por baixo do programa e, mais importante, se o que o programa está testando refletirá o uso real pretendido para o computador. Existem, então, alguns pontos a destacar:

• Um benchmark nunca refletirá o uso no mundo real. Sendo um programa totalmente automatizado, ele abrirá, escreverá, definirá, lerá, salvará, mostrará, olhará, navegará, moverá, calculará, atribuirá e fará muitas outras tarefas de uma maneira totalmente automatizada. Essa maneira nunca refletirá o ritmo que um ser humano fará em seu trabalho. Portanto, qualquer programa de benchmark que prometa resultados baseados no uso no mundo real está mentindo.
• Nem todos os benchmarks avaliam o desempenho de multitarefa. A grande maioria dos benchmarks avalia apenas tarefas executadas em série. Eles testam uma coisa e, então, a próxima. Eles nunca colocarão um aplicativo para fazer algo enquanto outro aplicativo está fazendo outra coisa (e, se assim for, normalmente eles tentam duas ou, no máximo, três instâncias). Na vida real, os usuários executam vários aplicativos simultaneamente. A maioria dos usuários abre muitos aplicativos ao mesmo tempo (o Sistema Operacional também executa muitas tarefas enquanto realizamos nossas tarefas diárias). Vale a pena mencionar que um benchmark que reflete apenas um processo/aplicativo não escala linearmente com o segundo, terceiro e o restante dos processos/aplicativos. Portanto, na tecnologia multicore moderna, é importante considerar os resultados de um programa de benchmark com ressalvas.
• “Taxa” não é o mesmo que “desempenho”. Taxa é apenas um número dado pelo programa. Desempenho é algo mais complicado. O número da taxa depende do programa de benchmark e da escala declarada por seus desenvolvedores. Desempenho é a realização de uma determinada tarefa medida em relação a padrões predefinidos conhecidos de precisão, integridade, custo e velocidade (The Business Dictionary, 2017). Portanto, nenhuma taxa de programa de benchmark reflete um índice de desempenho.
• Benchmarks são imprecisos. A variação na taxa de um programa de benchmark pode ser de até 10 % (às vezes, mais). Essas taxas de benchmark são sempre subjetivas, o que é contrário aos princípios objetivos da ciência e da tecnologia. É por isso que um programa de benchmark deve ser executado pelo menos 3 vezes para calcular uma média da taxa fornecida. Após determinar a média, espera-se pelo menos uma variação de +/- 3 % do resultado (tal variação pode ser calculada com base nos resultados coletados).
• Resultados de benchmark podem ser manipulados. Existem maneiras de manipular os resultados de um programa de benchmark e oferecer taxas artificialmente altas apenas para impressionar o usuário. Isso pode ser feito por meio de muitas técnicas, como ajustes excessivos, configurações no BIOS, alteração de hardware, uso de drivers especiais, manipulação de código e outros. As taxas de benchmark podem ser obtidas com configurações irreais em comparação com a forma como o computador será usado na prática: o sistema deve estar livre de programas e processos e ter valores específicos que dependem do benchmark em questão, e isso não reflete a maneira como o computador será usado na produtividade. Como Henry Newman declarou: “O que um benchmark nos diz é: 1) Quanto hardware um fornecedor consegue colocar em uma caixa, 2) Quão bem a equipe do fornecedor consegue otimizar o software [para o benchmark], e 3) O quanto o fornecedor quer fechar o negócio.” (Olds & OrionX, 2011) Se não houver um protocolo de benchmark claramente definido pelo cliente, a porta estará aberta para qualquer truque que o responsável pelo benchmark possa fazer para atingir (ou superar) os resultados desejados e impressionar o cliente.

No final, um programa de benchmark não é uma ferramenta precisa e deve ser usado com cuidado. Como Henry Newman citou em uma comunicação pessoal, “Comparar ferramentas de desempenho de sistema […] com […] benchmarks é como comparar maçãs com porcos voadores.” (Carrier, 2012)

As pontuações fornecidas por um benchmark devem ser usadas em conjunto com outros benchmarks e detalhes adicionais para obter uma compreensão completa do desempenho geral do sistema. O benchmark, no melhor dos casos, está apenas “medindo a velocidade” de um computador, mas existem muitos outros aspectos que precisam ser levados em conta: padrões comerciais, padrões militares, funcionalidade, recursos, certificações, preço, entre outros.

Se o computador avaliado para compra precisar atender a uma variedade de requisitos de usuário diferentes, é melhor predeterminar os casos de uso pretendidos para que um conjunto detalhado de critérios de qualificação apropriados seja estabelecido. Na maioria dos casos, o computador provavelmente será usado em um ou mais dos seguintes contextos:

• Será usado com ambientes operacionais gráficos atuais (Windows 10, ou distribuições GNU/Linux, no mínimo)
  • Ou se será usado com versões anteriores de sistemas operacionais, como Windows 7 ou Windows 8.1, ou uma distribuição GNU/Linux anterior.
• Produtividade Básica (Não mais que 5 aplicativos em execução, incluindo):
  • Antivírus
  • Processamento de texto
  • E-mail
  • Uso leve de planilhas
  • Aplicativos baseados na Web
  • Navegação na Web com não mais que 6 abas abertas.
• Produtividade Padrão (5 a 10 aplicativos em execução, incluindo):
  • O mesmo que Produtividade Básica, e também…
  • Aplicativos de escritório (processamento de texto com manipulação de imagem, planilhas com fórmulas e alguns scripts, apresentações, gerenciamento básico de banco de dados)
  • Navegação na Web com até 15 abas
  • Conferência Web
  • Visualização e edição simples de imagens e vídeos
  • Educação
  • Pode assumir uso copioso de vídeos, imagens, animações, acesso à Web e aplicativos que atualmente usam computação acelerada.
• Usuário Avançado (Mais de 10 aplicativos em execução, incluindo):
  • O mesmo que Produtividade Padrão, e também…
  • Desenvolvimento de aplicativos
    • Usando linguagens e ambientes de programação
    • Criar, gerenciar e testar bancos de dados,
    • Ambiente de teste com virtualização
    • Ambientes de teste controlados
  • Programas para pesquisa científica
    • Aplicativos especializados
    • Aplicativos de engenharia e científicos
    • Realidade Virtual
• Apenas para conhecimento geral, jogos são atualmente considerados computação de alto desempenho (Stevenson, Le Du, & El Afrit, 2011)
• Outros critérios
  • É necessário baixo consumo de energia?
  • É importante ou limitado o espaço ocupado pelo computador?
  • A mobilidade é necessária?
  • A autonomia da bateria é importante?
  • O peso é importante?
  • Certos outros usos que impliquem em uso portátil em ambientes hostis, empoeirados ou ruidosos

O termo no título desta seção pode parecer estranho, mas, na verdade, é uma questão que geralmente é ignorada ou negligenciada. Refere-se à seguinte pergunta: Qual tempo de resposta realmente importa para o usuário? Velocidade e desempenho são, na verdade, termos relativos. Ilya Grigorik propõe um conceito interessante do que a palavra “desempenho” significa.

“Desempenho não são apenas milissegundos, quadros e megabytes. É também como esses milissegundos, quadros e megabytes se traduzem em como o usuário percebe o aplicativo.” (Grigorik, 2014)

Cada aplicativo prescreve seu próprio conjunto de requisitos de acordo com critérios de negócios, contexto, expectativas do usuário e constantes de tempo de processamento perceptivo totalmente orientados para o usuário. Novamente, as expectativas do usuário têm uma relação com a primeira lei de Maister; “Satisfação é igual a percepção menos expectativa.” (Maister, 1985) Não importa o quanto a vida acelere, ou pelo menos seja percebida como acelerada (1 quadro a cada 66 ms), nossos tempos de reação permanecem constantes. Se considerarmos que um usuário pode ver cerca de 15 quadros por segundo de acordo com estudos tradicionais (Thorpe, Fize, & Marlot, 1996), a tabela a seguir (baseada no Padrão Militar 1472G) dá uma ideia clara do tempo de resposta que um usuário normalmente espera. Isso é independente do tipo de aplicativo (instalado no computador ou online) ou mídia (laptop, desktop ou dispositivo móvel).

Tempo Real e Percepção do Usuário (Seow, 2008)

• 0 – 100 ms: Instantâneo
• 100 – 500 ms: Imediato
• 500 – 1000 ms: Rápido
• 1 – 10 s: Um atraso é percebido, mas o usuário não perde o foco.
• +10 s: O computador está muito lento para manter a atenção do usuário.

Para que a resposta a uma solicitação do usuário seja percebida como rápida, ela deve chegar em menos de um segundo. Se levar um segundo ou mais, o usuário pode perceber um certo atraso, mas sua atenção não será desviada da tarefa. Após 10 segundos—a menos que o programa entregue algum tipo de informação ao usuário—a tarefa será normalmente abandonada e o usuário sentirá incômodo. Se o computador em avaliação puder entregar respostas em tempo comparável ou em menos de 10 segundos, o usuário aproveitará mais o computador. Esses limites são muito mais úteis no mundo real do que os resultados de programas de benchmark, que não oferecem orientação clara quanto aos seus significados.

Dito isso, em um benchmark eficaz, o cliente deve saber: como ele será aplicado, a análise e as conclusões que serão obtidas dele. Para a análise, é importante entender ou trazer:

• Um limite ou referência do resultado mínimo esperado
• O que está prestes a ser testado
• Quais são os fatores limitantes
• Qualquer perturbação que possa afetar os resultados
• Os detalhes do sistema testado
• O preço (pelo menos, a média) do sistema testado
• Quais conclusões se pretende alcançar com os resultados

O limite pode ser obtido em sites públicos (como a Futuremark) ou pode ser criado localmente a partir de um computador atualmente em uso e com uma boa configuração, a fim de definir a base para cada benchmark dos computadores prestes a serem oferecidos. Anote os detalhes da configuração deste computador usado como base (processador, memória [quantidade, velocidade, configuração, tempos], armazenamento, gráficos e monitor) para ter uma ideia clara dele.

A análise de benchmarks requer tempo e experiência para ser feita corretamente. Como dito, a parte mais importante é determinar o que está prestes a ser medido e se os resultados obtidos são significativos para o uso pretendido dos computadores.

A seguir, propõe-se um protocolo de benchmarking para garantir—tanto quanto possível—resultados justos e realistas dos benchmarks selecionados ou aplicados.

Recomenda-se para os processos de configuração e benchmarking não deixar o responsável pelo benchmark sozinho, especialmente se o responsável for um terceiro. O cliente deve designar uma testemunha para anotar tudo o que o responsável pelo benchmark fizer com a máquina para configurá-la para o processo de benchmark. Além disso, a testemunha também deve notar quaisquer mudanças ou modificações que o responsável pelo benchmark fizer após cada tipo de teste de benchmark. Se você, como cliente, tiver um protocolo bem definido, então o responsável pelo benchmark não deve violá-lo apenas para ganhar o processo de benchmark. O responsável pelo benchmark e a testemunha não devem ser a mesma pessoa, novamente, especialmente se o responsável pelo benchmark for um terceiro.

Não importa a marca ou o hardware oferecido, todos os computadores devem atender aos critérios de configuração:

• Se você pediu processadores quad-core físicos, todos eles devem ter quatro núcleos físicos.
• Se você pediu determinada quantidade, velocidade e configuração de RAM, verifique se todos os computadores têm a mesma configuração. Anote quaisquer diferenças:
  • Tamanho
  • Velocidade (MT/s)
  • Tempos e latências (CAS, RAS, tRAS, tRC, Frequência).
  • Canal único vs Canal Duplo
• Se você pediu determinado tipo de armazenamento, verifique se todos os computadores incluem esse tipo de armazenamento. Anote quaisquer diferenças encontradas (taxa de transferência, tempos de busca e tempos de gravação):
  • Disco Rígido Rotativo Padrão (5400RPM, 7200RPM, 10000RPM, SSHD)
  • SSD
• A placa de vídeo deve atender ao Shader Model 6.1 (DirectX 12.1) para Windows 10 ou Shader Model 5 (DirectX 11) para versões anteriores do Windows.
• O monitor deve atender aos mesmos recursos em cada computador
  • Tempos de atualização
  • Tempos de resposta (ms)
  • Resolução (resoluções mais altas podem trazer números de benchmark mais baixos)
  • Profundidade de cor
• O Sistema Operacional deve ser a mesma versão e compilação.
  • No Windows, você pode ver a versão e a compilação digitando winver e Retorno na caixa da Cortana ou após pressionar Windows+R para abrir a janela Executar.
• Todo computador deve ter instalado apenas os drivers atuais aprovados pelo fabricante do computador. Nota: Não permita o uso de drivers especiais ou drivers ajustados trazidos por um fabricante de componentes, pois eles podem trazer resultados falsos. Evite o uso de drivers fora dos validados e publicamente disponíveis no site ou na ferramenta de configuração do fabricante do computador.
• Configure o computador no modo Equilibrado. Esta é a maneira pela qual os computadores devem ser usados pelo cliente e é a maneira mais fiel de obter resultados dos benchmarks.
• Instale os aplicativos comumente usados pelo cliente. Não importa se eles não serão usados no teste, é a maneira como os computadores serão usados.
• Instale qualquer outro software (como antivírus e ferramentas) exigido pelo cliente. Isso definirá a configuração o mais próximo possível de como o usuário final a usará.
• Instale os programas de benchmark.

Uma vez que os computadores estão instalados, recomenda-se fazer um benchmarking quente. Um benchmarking quente precisa de um engenheiro (Engenheiro, não um técnico) anotando tudo o que está acontecendo durante o processo de benchmark (partes ignoradas do teste, etapas ausentes, comportamentos estranhos na tela, figuras ou imagens mal desenhadas, e assim por diante). Tais anomalias devem ser anotadas e relatadas. É aconselhável evitar o benchmarking a frio (apenas executar o benchmark, afastar-se do computador e, então, retornar apenas para anotar o resultado) porque nenhuma evidência de comportamento estranho durante o benchmark será notada. Como declarado, existem maneiras de manipular as taxas de benchmark e fazer um benchmark a frio é a melhor maneira de perder esse tipo de prática.

Como as taxas de benchmark podem resultar em variações de 5 a 15 %, recomenda-se executar cada teste pelo menos 3 vezes. Cada vez precisará de uma reinicialização do computador, aguardar cerca de 5 minutos após o aparecimento da área de trabalho e, então, executar o benchmark novamente. Após cada execução de benchmark, recomenda-se fazer uma captura de tela do resultado para salvar a evidência. Isso deve ser feito em cada programa de benchmark selecionado.

Cabe ao cliente decidir se as diferentes taxas obtidas através de cada execução de cada benchmark serão calculadas pela média, ou tomando o valor mais alto ou mais baixo. Qualquer que seja a decisão que o cliente tome, recomenda-se aplicá-la a todos os diferentes benchmarks usados. Como sugestão, escolha a média.

Após obter tais resultados, eles podem ser normalizados (como no corpo deste documento) e, então, convertidos linearmente em tempos. Com o preço dos computadores, o cliente também pode avaliar qual dos sistemas oferece a melhor relação preço/desempenho.

Um processo de benchmarking requer tempo, experiência e paciência. Se forem bem feitos, os programas de benchmark podem dar uma boa ideia sobre o desempenho esperado do computador. Tudo anotado pela testemunha será útil para determinar o que o concorrente precisará fornecer caso seja selecionado. A configuração (processador, RAM [quantidade, velocidade, tempos, modo de canal], armazenamento [tipo, taxa de transferência, capacidade], monitor, fator de forma, etc.) anotada durante o processo de benchmarking será útil para garantir que o computador entregue seja configurado exatamente como testado. Isso é importante porque alguns fornecedores abusivos podem entregar um computador especialmente configurado apenas para o processo de teste, e um muito diferente no final. Portanto, isso ajudará o cliente a obter exatamente o que foi testado.

De toda a discussão anterior, pode-se concluir o seguinte:

• As compras que o cliente está fazendo são para computadores, não apenas um processador ou determinado componente. É, portanto, necessário levar o sistema geral (holisticamente) em conta ao tomar uma decisão de compra.
• O desempenho de um computador deriva de todos os seus elementos. Isso inclui hardware e software. O desempenho geral do computador será sempre igual ao desempenho de seu elemento mais lento.
• É necessário levar em conta medidas de economia de energia, geração de calor, a estabilidade do computador, suas certificações para uso comercial e os serviços de segurança que oferece. Mais do que apenas velocidade baseada em benchmark, a tecnologia atual exige que o consumo reduzido de energia e os serviços de segurança sejam fornecidos.
• É importante estar ciente de que as novas tecnologias integradas aos aplicativos e sistemas operacionais alavancam muito mais do que apenas o processador. Em vez disso, elas se concentram mais em outros componentes, como a CPU, GPGPU, barramentos, velocidade da RAM e taxa de transferência do disco.

Uma medida verdadeira do poder de computação é obtida quando o computador é medido holisticamente, não apenas na área de processamento serial ou da CPU. O cliente que usa ferramentas de escritório, navegadores da Web, compressão de arquivos, reprodutores de vídeo, ferramentas de teleconferência, aplicativos baseados na Web e coisas semelhantes aproveitará todos os recursos dessas novas tecnologias com arquitetura heterogênea.

Uma nota final sobre isso é que um limite ou referência é sempre necessário para ter uma ideia melhor das melhorias de desempenho prestes a receber. Se você não quiser usar a medida base oferecida pela FutureMark para um “PC de Escritório de Referência” até a data atual, você pode medir seu computador base em seu escritório com base em seus próprios critérios (talvez, um computador com o qual você se sinta confortável com seu desempenho padrão). Uma vez que você execute o benchmark para obter seus resultados, você pode, então, usar esses resultados como um limite para ter taxas mínimas esperadas das soluções oferecidas. Apenas mais uma coisa a notar é que “taxas” não são o mesmo que “desempenho”. Uma “taxa” apenas dá uma qualificação dos processos executados pelo programa de benchmark. “Desempenho” é o resultado real que você obterá ao usar esse computador em suas próprias tarefas.

Anon, E. A., & Gray, J. (Fevereiro, 1985). A Measure of Transaction Processing Power. Recuperado em 22 de março de 2015, de Internet Archive: https://archive.org/details/bitsavers_ta...

Carrier, J. (24 de abril de 2012). HPCS I/O Scenarios. Recuperado de OpenSFS: http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 de março de 2015). Thrashing. Recuperado de Computer hope: http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1 ed.). EUA: Pearson Education.

Grigorik, I. (12 de março de 2014). Speed, Performance, and Human Perception. (Fluent, Ed.) São Francisco, CA, EUA. Recuperado em 22 de março de 2015, de https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 de dezembro de 2006). Multicore, SMP and SMT Processors. Recuperado em 22 de março de 2015, de HoffmanLabs: http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, Ed.) Recuperado em 22 de março de 2015, de David Maister: Professional Business, Professional Life: http://davidmaister.com/wp-content/theme...

Mallik, A. (2007). Hollistic Computer Architectures based on Application, User, and Process Characteristics. Evanston, Illinois, EUA: UMI.

Newman, H. (2015). Data Storage Issues: Big Data Benchmarking. Recuperado de InfoStor: http://www.infostor.com/index/blogs_new/...

Olds, D., & OrionX. (19 de dezembro de 2011). Benchmarks are $%#&@!! Recuperado de The Register: http://www.theregister.co.uk/2011/12/19/...

Osterhage, W. (2013). Computer Performance Optimization (1 ed.). (Springer-Verlag, Trans.) Niederbachem, Alemanha: Springer-Verlag Berlin Heidelberg.

Seow, S. (2008). Designing and Engineering Time. Boston, EUA: Prentice Hall.

Smaalders, B. (23 de fevereiro de 2006). Performance Anti-Patterns. doi:1542-7790/06/0200

Stevenson, A., Le Du, Y., & El Afrit, M. (Março, 2011). High Performance Computing on Gamer PCs. Recuperado de ArsTechnica: http://arstechnica.com/science/2011/03/h...

The Business Dictionary. (2017). Performance. Recuperado de The Business Dictionary: http://www.businessdictionary.com/defini...

Thorpe, S., Fize, D., & Marlot, C. (6 de junho de 1996). Speed of processing in the human visual system. Nature, 381, 520-522. Recuperado de Quora: http://cns.bu.edu/Profiles/Mingolla.html...

Traeger, A., Zadok, E., Joukov, N., & Wright, C. (2008, Maio). A Nine Year Study of File System and Storage Benchmarking. Recuperado em 22 de março de 2015, de File systems and Storage Lab (FSL): http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 de outubro de 2011). The Perception of Performance. Recuperado em 22 de março de 2015, de Sitepoint: http://www.sitepoint.com/the-perception-...