Busca binária

O objetivo deste post é apresentar um meio eficiente de busca de objetos em memória.

O surgimento da sintaxe LINQ, assim como a utilização de query methods, facilitou a busca em memória. Com estes recursos podemos facilmente executar queries em arrays, coleções e listas de tipos genéricos. O uso deste modelo de sintaxe agiliza o processo de desenvolvimento por tornar a busca em memória trivial e de simples codificação.

Mas, ao adotarmos esse modelo de sintaxe, estamos realmente escrevendo código performático? Será que essas consultas em memória são o modelo mais rápido de pesquisa? Não estaríamos perdemos poder computacional ou tempo de processamento ao adotar estes recursos em determinados cenários de pesquisa em memória?

Dada a necessidade de executar consultas eficientes e com baixo custo computacional, passamos a evitar consultas que consumam muitos recursos computacionais e que sejam lentas.

A busca binária é um algoritmo de busca que segue o paradigma da divisão e conquista. Partindo do pressuposto de que o conjunto de elementos está ordenado, são executadas diversas divisões do espaço de busca restringindo o possível local no qual o elemento buscado está posicionado. A imagem a seguir ilustra o processo de divisão do conjunto de elementos realizado pela busca de elementos.

clip_image002

Saiba mais

Sobre estes anúncios

Visual Studio Summit 2014 – Profiling de Aplicações .NET

Tive a felicidade de participar pela terceira vez do Visual Studio Summit, evento sobre tecnologias Microsoft.

Nesta última participação palestrei sobre Profiling de Aplicações .NET.

Aqui existe um link para o evento Visual Studio Summit 2014.

Mais detalhes sobre o uso de profiling podem ser encontrados neste link: Profiling de Aplicações .NET

Saiba mais

Profiling de Aplicações .NET

Mesmo com o melhor desempenho e os melhores profissionais, problemas relacionados a performance podem surgir. Fazer com que uma aplicação execute de forma performática pode parecer uma tarefa fácil, mas isso pode se tornar uma arte oculta.

Ferramentas de profiling monitoram a execução de uma aplicação com o objetivo de medir os recursos computacionais (tempo, processamento e memória) gastos por um método por toda a sua execução. Seu objetivo é identificar pontos na aplicação que causem problemas em sua execução.

O profiling de aplicações .NET é mais complexo do que aplicações em código de máquina, pois o .NET faz uso de recursos como Application Domains, Garbage Collection, Exception Handling e Just-in-Time Compilation, recursos que tornam o processo de captura dos métodos em execução mais complexo.

Saiba mais

Entity Framework – Melhores práticas em busca de performance

Separei neste post algumas dicas de como tornar suas aplicações com Entity Framework mais performáticas. As dicas abaixo se resumem a um grupo de boas práticas que costumo aplicar em meus projetos. Algumas desta dicas não se aplicam apenas ao Entity Framework, mas se aplicam a outras ferramentas ORM ou técnicas de modelagem de sua camada de acesso a dados.

Tornando sua aplicação mais performática

Saiba mais

Considerações de Performance do Entity Framework 5

Olá pessoal,

Este post será bastante sucinto. Semana passada o time de ADO.Net liberou um artigo com considerações de performance existentes no Entity Framework 5.

Este artigo é bastante interessante e detalhe diversos aspectos do Entity Framework, tais como:
- Cache
- Opções de execução de queries
- Estratégias de herança
- Lazy loading
- Comparações de performance

Saiba mais

Windows Phone – Teste de Performance

Participando de um projeto de Windows Phone surgiu a necessidade de testar a performance do aparelho, e da plataforma em si. Este teste tinha como base a pergunta: "O quão rápido é o aparelho ao carregar uma quantidade X de elementos em um listbox?"

Essa dúvida surgiu devido a característica do aplicativo de armazenar registros diariamente, e na qual o usuário poderia listar uma quantidade bastante grande de registros na interface visual. Diante deste cenário muitas dúvidas surgiram: "Quanto tempo leva para carregar o controle?", "Qual a quantidade ideal de registros a serem carregados?", "Como o silverlight vai se comportar ao carregar uma quantidade grande de itens?", "O layout esta complexo o suficiente para fazer o aplicativo ficar lento?" "Quanto esses dados em memória podem deixar o device lento?"

Essas dúvidas poderiam apenas ser respondidas com um experimento, e este trabalhou coube a mim. Diante disso construí um teste de carga bastante simples, cujo funcionamento era: Criar muitos registros na base do SQL CE e listar uma quantidade bastante grande de registros de uma única vez.

Então, criei três funções básicas no aplicativo, sendo elas:

1 – Geração de valores: esta funcionalidade inseria 1000 registros no SQL CE toda vez que fosse acionada, populando a base com uma quantidade grande (comparada ao porte do dispositivo) de registros. A estrutura da classe que produziu esses dados na base de dados é a da imagem abaixo:

[Table(Name="tbLoadTest")]
public class TargetItem
{
    [Column(Name="ldtId", IsPrimaryKey=true, IsDbGenerated=true, CanBeNull=false,AutoSync=AutoSync.OnInsert)]
    public int Id { get; set; }

    [Column(Name="ldtTitle", CanBeNull=false)]
    public string Title { get; set; }

    [Column(Name = "ldtDescription", CanBeNull = false)]
    public string Description { get; set; }

    [Column(Name = "ldtValue", CanBeNull = false)]
    public decimal Value { get; set; }

    [Column(Name = "ldtInsertDate", CanBeNull = false)]
    public DateTime InsertDate { get; set; }
}

2 – Apagar itens do banco de dados: para limpar o banco de dados (e não deixar meu celular poluído) foi criada uma funcionalidade de expurgo dos dados.

3 – Listagem de arquivos: essa é a motivação de nosso teste de carga. Saber o quão rápido um determinado layout poderia ser carregado na tela do device e qual a quantidade ideal de registros que podem ser carregados sem interferir na performance do aparelho.

O interface do teste de carga ficou assim:

performance

RESULTADOS

Os resultados foram bastante interessantes. A carga de mil itens foi bastante rápida, em menos de 1,5 segundos foi possível incluir mil registros de uma única vez no SQL Ce. A carga de itens no listbox foi mais surpreendente ainda, em 1 segundo foram carregados mil itens na tela, em 2 segundos foram carregados mil registros e em 3,5 segundos foram carregados cinco mil registros na tela. O único ponto que a performance não agradou foi a parte de exclusão de registros, pois ela demorou muito para excluir todos os registros (demorou 1m35s para excluir 5000 registros), possivelmente isso esteja atrelado ao funcionamento do SQL CE e de seu transaction log.

Mas em suma, a performance do Windows Phone esta acima do esperado e seus resultados foram bastante satisfatórios.

APARELHO UTILIZADO

Samsung I8700 Omnia 7

OS: Microsoft Windows Phone 7.5

Chipset: Qualcomm QSD8250 Snapdragon

CPU: 1 GHz Scorpion

GPU: Adreno 200

Referência: http://www.gsmarena.com/samsung_i8700_omnia_7-3537.php

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 66 outros seguidores