Esse é o primeiro de uma série de artigos onde vou mostrar algumas dicas, ferramentas e truques para analisar aplicações e identificar problemas, as vezes isso será feito só com o dump de memória da aplicação o que vai deixar o trabalho mais divertido :D.

Voltando ao assunto das Strigs, o que não falei no primeiro artigo, é que essa tabela de strings é montada em tempo de compilação, isso significa que durante a execução do sistema podemos ter strings duplicadas em memória,e no caso de uma aplicação com problemas de consumo de memória, já temos um bom lugar para começar a análise!

Nesse artigo estou utilizando a ferramenta YourKit Profiler for .NET..

Veja o código abaixo:

Nesse código incluímos 1000 vezes a string “Althmann” em uma lista, a parte boa é que em tempo de compilação isso será resolvido, e a tabela de strings vai entrar em ação, teremos só 1 “Althmann” em memória.

Mas logo abaixo adicionamos na mesma lista, um texto qualquer que o usuário digitar, é aqui que a brincadeira fica divertida. Não temos muito controle do que será informado no sistema, ou de XMLs gigantes carregados, ou seja, quase tudo vira string nos sistemas, e dependendo do tamanho das strings e da sua duplicação o consumo de memória pode ser elevado.

Nesse teste eu vou escrever 10 vezes a seguinte frase.

Preciso acabar logo o artigo porque quero jogar Diablo 3

Utilizando o YourKit Profiler, consigo executar facilmente algumas análises de possíveis memory leaks, um dos itens que ele analisa por padrão é a duplicação de strings, veja na imagem abaixo ele mostrando as 10 strings duplicadas em memória.

O bom é que a ferramenta já da dicas de possíveis formas de resolver o problema, a que vou utilizar é a String.Intern.

Veja o novo código usando agora String.Intern.

Explicando de uma forma simples, quando eu faço String.Intern(Console.ReadLine()), antes de adicionar a string na lista, será feita uma verificação se essa string já está na tabela de strings, se não estiver adiciona e se estiver retorna a referência.

Com isso repetindo novamente a frase anterior 10 vezes o YourKit Profiler não acusa mais a minha frase repetida em memória.

Simples e com ótimo resultado, então isso é regra, se eu tenho um consumo elevado de memória vou usar String.Intern?

De forma alguma! Nem tudo são flores, temos que levar em consideração performance, afinal existe uma operação para verificar se essa string já existe, mas ainda farei alguns testes mais sérios para verificar se realmente é um problema. Mais um detalhe, prestem muita atenção no texto abaixo, ao tentar resolver um problema podemos gerar outros ;).

If you are trying to reduce the total amount of memory your application allocates, keep in mind that interning a string has two unwanted side effects. First, the memory allocated for interned String objects is not likely be released until the common language runtime (CLR) terminates. The reason is that the CLR’s reference to the interned String object can persist after your application, or even your application domain, terminates. Second, to intern a string, you must first create the string. The memory used by the String object must still be allocated, even though the memory will eventually be garbage collected.

Por hoje é isso.

Abraços

Já escrevi sobre algumas keywords do C# aqui no blog, e hoje vou falar sobre as keywords const e readonly, que são parecidas mas não iguais ;).

const

Com a keyword const, nós definimos que o valor de uma variável ou filtro é constante, ou seja, não pode ser alterado após sua inicialização, e só podemos definir o valor na declaração da variável ou field.

readonly

Diferente da keyword const, com a keyword readonly, podemos utilizá-la apenas em fields, e a definição do valor pode ser feito na sua declaração ou no construtor da classe, tentar declarar o valor de um field readonly em um método da classe por exemplo da erro de compilação.

Por hoje é só até o próximo post.

Abraços.

Nesse código existem dois objetos importantes da API do RavenDB, o DocumentStore e o DocumentSession, vamos começar pelo  Store.

De uma forma simples, é com o DocumentStore que criamos a nossa comunicação com o RavenDB, por isso informamos no construtor da classe o endereço do servidor, mas devemos lembrar de chamar o método Initialize do DocumentStore, só instanciar a classe não é suficiente.

Com o DocumentStore criado, podemos criar o DocumentSession chamando o método OpenSession, é com o DocumentSession que conseguimos realizar operações no banco de dados, inclusões, consultas, alteraçoes ou seja o famoso CRUD, create, read, update, delete.

Por hoje é isso, informações mais detalhadas sobre DocumentStore e DocumentSession aqui.

Abraços.

O projeto está no github e é liderado pelo Ayende Rahien, se você não conhece o cara, recomendo acompanhar o blog e ver outros produtos que ele faz ;).

Apesar do site do RavenDB não ser um exemplo em documentação, vou listar algumas funcionalidades do RavenDB:

• Schema free
• Scalable (sharding, multi-tynancy, replication)
• Transactional
• Multi-level caching
• Full-text search (built on top of Lucene)
• High performance (aqui depois vou fazer um teste de desempenho entre o RavenDB, MongoDB e o SQL Server só para colocar um banco relacional na jogada)

Existem outros detalhes interessantes, por exemplo, a possibilidade de rodar “embeded”, não precisando instanciar um servidor, e também tem o Rave Studio que permite visualizar e gerenciar seus documentos.

Pretendo nos outros artigos detalhar cada uma dessas opções do RavenDB, mas para não terminar o primeiro artigo sem código, após o download feito, é só executar o Raven.Server.exe que fica na pasta Server, com isso já temos o servidor rodando e podemos acessar o Raven Studio pela url http://localhost:8080.

E o código do teste que inseriu esses albuns.

Por hoje é só, depois detalhes da implementação e mais informações sobre o RabenDB.

Abraços

[Serializable]
[DataContract]
public class Album
{
    [DataMember]
    public string Titulo { get; set; }

    [DataMember]
    public int AnoDeLancamento { get; set; }

    [DataMember]
    public List<Musica> Musicas { get; set; }

    [DataMember]
    public Banda Banda { get; set; }

    public Album()
    {
        Banda = new Banda() {Nome = Environment.TickCount.ToString()};
        Musicas = new List();
        for (int i = 0; i < 10; i++)
        {
            Musicas.Add(new Musica {Duracao = new TimeSpan(0, i, 0), Nome = i.ToString()});
        }
    }
}

[Serializable]
[DataContract]
public class Musica
{
    [DataMember]
    public string Nome { get; set; }

    [DataMember]
    public TimeSpan Duracao { get; set; }
}

[Serializable]
[DataContract]
public class Banda
{
    [DataMember]
    public string Nome { get; set; }

    [DataMember]
    public List Integrantes { get; set; }

    public Banda()
    {
        Integrantes = new List<Integrante>();
        for (int i = 0; i < 5; i++)
        {
            Integrantes.Add(new Integrante {Nome = string.Format("Integrante {0}", i)});
        }
    }
}

[Serializable]
[DataContract]
public class Integrante
{
    [DataMember]
    public string Nome { get; set; }
}

Ahhh Márcio mas esse objeto complexo não é tão complexo. Bom eu considero que está bom, caso alguém faça algum teste mais ousado por favor me envie!

Mesma execução explicada no artigo anterior, 100.000 serializações, 100.000 deserializações, e vamos aos resultados.

Além do gráfico, vou descrever os resultados, e novamente o Protobuf-net mostra que é disparado mais rápido que qualquer serializador disponível nativamente no .NET.

Protobuf-net
Serialização: 234 ms
Deserialização: 1154 ms

BinaryFormatter
Serialização: 6833 ms
Deserialização: 8019 ms

DataContractSerializer
Serialização: 1887 ms
Deserialização: 4790 ms

XmlSerializer
Serialização: 3385 ms
Deserialização: 7036 ms

Código fonte no github.

Abraços.

E para nossa alegria o Google sabe isso, e ele criou o Google Protocol Buffers, é simples e rápido, na verdade muito rápido!!! Recomendo a leitura da documentação para entender o funcionamento do Protocol Buffers.

Uma descrição rápida do Protocol Buffers.

protocol buffers is the name of the binary serialization format used by Google for much of their data communications. It is designed to be:

small in size – efficient data storage (far smaller than xml) cheap to process – both at the client and server platform independent – portable between different programming architectures extensible – to add new data to old messages

Já que o Google mostrou pra todo mundo como fazer, uma implementação do Protocol Buffers foi criada em .net, chamada Protobuf-net, ela funciona com praticamente todas as versões do .NET, suporta Silverlight, Mono e está no Google Code, então quem quiser pode ajudar no projeto! ;)

Serializar e deserializar objetos com o Protobuf-net é simples, então não vou ficar mostrando exemplos, mas vou colocar um teste de desempenho que fiz para comparar alguns tipos de serializações nativas do .NET contra o Protobuf-net.

A idéia do teste é simples, vou adicionar em uma lista de Albuns 100.000 albuns, a primeira parte que consistem em serializar vou percorrer essa lista e criar uma nova lista de byte[] com cada album serializado, e a parte da deserialização percorro a lista com byte[] da serialização e crio uma nova lista com Albuns.

A classe Album é simples, e está marcada com nossos conhecidos atributos de serialização e de contratos.

[Serializable]
[DataContract]
public class Album
{
    [DataMember]
    public string Titulo { get; set; }
    [DataMember]
    public int AnoDeLancamento { get; set; }
}

E agora o código que cria a lista com os albuns que serão serializados.

private const int TotalDeAlbuns = 100000;
private static readonly List Albuns = Enumerable.Range(0, TotalDeAlbuns).Select(x => CriarAlbum(x)).ToList(); 

private static Album CriarAlbum(int numeroDoAlbum)
{
    return new Album {AnoDeLancamento = numeroDoAlbum, Titulo = numeroDoAlbum.ToString()};
}

Eu fiz os testes utilizando as seguintes formatos de serialização:

• Protobuf-net
• BinaryFormatter
• DataContractSerializer
• XmlSerializer

E agora finalmente os códigos, são iguais só alterando o formato da serialização.

private static void TestesComProtobufNet()
{
    var albunsSerializados = new List();
    var albunsDesserializados = new List();

    Contador.Iniciar();

    foreach (var album in Albuns)
    {
        using (var memoryStream = new MemoryStream())
        {
            Serializer.Serialize(memoryStream, album);
            albunsSerializados.Add(memoryStream.ToArray());
        }
    }

    Contador.Parar();

    Console.WriteLine("Serializando {0} objetos com Protobuf-net: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);

    Contador.Iniciar();

    foreach (var album in albunsSerializados)
    {
        using (var memoryStream = new MemoryStream(album))
        {
            albunsDesserializados.Add(Serializer.Deserialize(memoryStream));
        }
    }

    Contador.Parar();

    Console.WriteLine("Deserializando {0} objetos com Protobuf-net: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);
    Console.WriteLine();
}

private static void TestesComProtobufBinaryFormatter()
{
    var albunsSerializados = new List();
    var albunsDesserializados = new List();

    var binaryFormatter = new BinaryFormatter();

    Contador.Iniciar();

    foreach (var album in Albuns)
    {
        using (var memoryStream = new MemoryStream())
        {
            binaryFormatter.Serialize(memoryStream, album);
            albunsSerializados.Add(memoryStream.ToArray());
        }
    }

    Contador.Parar();

    Console.WriteLine("Serializando {0} objetos com BinaryFormatter: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);

    Contador.Iniciar();

    foreach (var album in albunsSerializados)
    {
        using (var memoryStream = new MemoryStream(album))
        {
            albunsDesserializados.Add((Album)binaryFormatter.Deserialize(memoryStream));
        }
    }

    Contador.Parar();

    Console.WriteLine("Deserializando {0} objetos com BinaryFormatter: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);
    Console.WriteLine();
}

private static void TestesComDataContractSerializer()
{
    var albunsSerializados = new List();
    var albunsDesserializados = new List();

    var dataContractSerializer = new DataContractSerializer(typeof (Album));

    Contador.Iniciar();

    foreach (var album in Albuns)
    {
        using (var memoryStream = new MemoryStream())
        {
            dataContractSerializer.WriteObject(memoryStream, album);
            albunsSerializados.Add(memoryStream.ToArray());
        }
    }

    Contador.Parar();

    Console.WriteLine("Serializando {0} objetos com DataContractSerializer: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);

    Contador.Iniciar();

    foreach (var album in albunsSerializados)
    {
        using (var memoryStream = new MemoryStream(album))
        {
            albunsDesserializados.Add((Album) dataContractSerializer.ReadObject(memoryStream));
        }
    }

    Contador.Parar();

    Console.WriteLine("Deserializando {0} objetos com DataContractSerializer: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);
    Console.WriteLine();
}

private static void TestesComXmlSerializer()
{
    var albunsSerializados = new List();
    var albunsDesserializados = new List();

    var xmlSerializer = new XmlSerializer(typeof (Album));

    Contador.Iniciar();

    foreach (var album in Albuns)
    {
        using (var memoryStream = new MemoryStream())
        {
            xmlSerializer.Serialize(memoryStream, album);
            albunsSerializados.Add(memoryStream.ToArray());
        }
    }

    Contador.Parar();

    Console.WriteLine("Serializando {0} objetos com XmlSerializer: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);

    Contador.Iniciar();

    foreach (var album in albunsSerializados)
    {
        using (var memoryStream = new MemoryStream(album))
        {
            albunsDesserializados.Add((Album)xmlSerializer.Deserialize(memoryStream));
        }
    }

    Contador.Parar();

    Console.WriteLine("Deserializando {0} objetos com XmlSerializer: {1} ms", TotalDeAlbuns, Contador.TempoTotalEmMilisegundos);
    Console.WriteLine();
}

Execute a aplicação 3 vezes, em Release, segue o gráfico com a média de tempo de cada formato de serialização. E o Protobuf-net realmente da um show.

É interessante analisar esses tempos, o XmlSerializer é muito lento, e o DataContractSerializer manda bem para serializar, mas para deserializar não é tão bom.

É importante ver que mesmo com o .NET disponibilizando vários formatos de serialização, precisamos sair da “zona de conforto” e buscar melhores alternativas, é claro que isso depende do cenário de cada um, mas caso esteja atendendo cenários críticos onde qualquer segundo faz diferença é sempre bom abrir a cabeça e aceitar novidades ;).

O código fonte do projeto está no github.

Abraços.

Mais uma dica simples, utilizando um recurso adicionado no .NET 4.0, para saber se o Sistema Operacional é 64 bits, ou o processo que está executando nossa lógica é 64 bits temos jeitos simples para fazer isso.

Para descobrir se o sistema operacional é 64 bits é só fazer:

Environment.Is64BitOperatingSystem

E para saber se o processo é 64 bits:

Environment.Is64BitProcess

Ambas as propriedades retornam um booleano.

Por enquanto é isso.

Abraços.

Trabalho criando ferramentas e frameworks pra outros desenvolvedores, e nem sempre quando disponibilizamos alguma API para utilização, podemos sair removendo métodos por exemplo, não sabemos quem utilizou, e se em alguma possível atualização o software vai parar de funcionar ou não, e o atributo Obsolete pode nos ajudar nesse cenário, informando o que está obsoleto na API e será descartado em breve, ou simplesmente recomendando uma alternativa melhor!

A utilização do atributo é simples, vou pegar o código do BasicIoC e criar um método obsoleto de propósito, só preciso informar a mensagem que será mostrada para quem for utilizar o método.

[Obsolete("This method is obsolete; use method Register instead.")]
public Container Map<T>()
{
    _baseType = typeof (T);
    return this;
}

E o interessante é que o Intellisense já ajuda o desenvolvedor mostrando que o método é obsoleto.

Isso não impede a utilização do método, mas mostra avisos quando compilamos que utilizamos um método obsoleto.

Mas podemos adicionar um segundo parâmetra booleano quando configuramos o atributo, forçando um erro de compilação caso existe algum código utilizando um método ou classe obsoleta.

[Obsolete("This method is obsolete; use method Register instead.", true)]
public Container Map<T>()
{
    _baseType = typeof (T);
    return this;
}

Agora o código não compila mais, no lugar de um aviso um erro de compilação é mostrado, mostrando que estamos utilizando um método obsoleto.

Por hoje é isso.

Até o próximo post.

A idéia é simples, .times vai executar o códido o número de vezes informado, upto vai executar o código o número de vezes incrementando do valor inicial até o final, e downto vai executar o código o número de vezes decrementando do valor inicial até o final.

Veja o código:

[sourcecode language="ruby"]
puts "testando times"
2.times {|i| print i, " "}
puts
puts "testando upto"
1.upto(5) {|i| print i, " "}
puts
puts "testando downto"
10.downto(5) {|i| print i, " "}
[/sourcecode]

Resultado:

Simples e interessante, no C# não temos nada disso, mas podemos criar algo parecido utilizando um pouco de Métodos de Extensão, não vou explicar nesse post o que são e como criar as extensões, vejam no post linkado.

Segue os códigos das Extensões e do aplicativo de teste:

[sourcecode language="csharp"]
public static class Extensions
{
public static void Times(this int value, Action<int> action)
{
for (int i = 0; i < value; i++)
{
action(i);
}
}

public static IEnumerable<int> UpTo(this int start, int end)
{
for (int i = start; i <= end; i++)
{
yield return i;
}
}

public static IEnumerable<int> DownTo(this int start, int end)
{
for (int i = start; i >= end; i–)
{
yield return i;
}
}

public static void Each<T>(this IEnumerable<T> enumerable, Action<T> action)
{
foreach (var value in enumerable)
{
action(value);
}
}
}

class Program
{
static void Main(string[] args)
{
Console.WriteLine("testando times");
3.Times(x => Console.Write("{0} ", x));
Console.WriteLine();
Console.WriteLine("testando upto");
5.UpTo(10).Each(x => Console.Write("{0} ", x));
Console.WriteLine();
Console.WriteLine("testando downto");
10.DownTo(5).Each(x => Console.Write("{0} ", x));

Console.ReadLine();
}
}
[/sourcecode]

E o resultado:

Bom é isso, o código é simples mas foi divertido e gostei do resultado final, apesar de achar que em Ruby fica muito melhor gostei do resultado final em C#, e para quem não conhece Ruby recomendo estudar, não precisa trabalhar com Ruby, mas é muito interessante conhecer novas tecnologias, mais sobre o que penso sobre isso nesse post..

Por enquanto é só, código no GitHub.

Abraços.

Sempre precisamos fazer upload de arquivos, fotos, documentos e é interessante disponibilizar para o usuário uma interface rica, com suporte a drag and drop, progresso do upload, upload de multiplos arquivos entre outras opções, e nisso o PlUpload é um ótimo plugin, apesar de não funcionar somente com JQuery, ele possui runtimes de Flash, Silverlight e alguns outros, mas hoje vou utilizar o Jquery queue widget para fazer uploads.

Para fazer download é só clicar aqui, existe uma versão gratuita, ou se alguém quiser pode também licenciar o plugin de upload, o que muda é suporte e ajuda os caras a ganhar um merecido dinheiro :).

Existem várias opções de runtime, e diversos arquivos no arquivo de download, segue os arquivos que utilizei no exemplo.

[sourcecode language="html"]
<script src="@Url.Content("~/Scripts/plupload.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/plupload.html4.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/plupload.html5.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.plupload.queue.js")" type="text/javascript"></script>
<link href="@Url.Content("~/Content/plupload/jquery.plupload.queue.css")" rel="stylesheet" type="text/css" />
[/sourcecode]

Um detalhe é que para funcionar corretamente, também adicione as imagens disponibilizadas no arquivo de download, e preste atenção no arquivo de .css para ver o diretório de colocar as imagens, ou altere o jquery.upload.queue.css para apontar para sua pasta de imagens.

Feito isso eu criei um método upload no meu controller plupload, segue o código que não é foco do artigo fazer o armazenamento dos arquivos :), e também repare no parâmetro do método que tem que ser HttpPostedFileBase.

[sourcecode language="csharp"]
[HttpPost]
public void Upload(HttpPostedFileBase file)
{
// Lógica para salvar a foto
}
[/sourcecode]

Feito isso precisamos configurar nosso HTML, que só vai ter uma div com um id específico, bem difícil assim mesmo :), é nessa div que o plugin de upload será montado.

[sourcecode language="html"]
<div id="upload"></div>
[/sourcecode]

E para finalizar, temos o JQuery que configura o plugin na div que criamos, detalhe para algumas configurações básicas do plugin, onde informo os runtimes que vamos utilizar, tamanho máximo de cada arquivo, a URL que ele vai enviar as fotos, e as extensões suportadas. Mais configurações podem ser encontradas na documentação do plugin.

[sourcecode language="javascript"]
<script type="text/javascript">
$(function () {

$("#upload").pluploadQueue({
runtimes : "html5,html4",
url : "/plupload/upload",
max_file_size : "4mb",
filters: [
{title : "Imagens", extensions : "jpg,png"}
]
});

});
</script>
[/sourcecode]

Feito isso é só testar e ver o upload funcionando, com progresso, opção para exclusão de itens antes de iniciar o upload, muito bom!

Código fonte no GitHub.

Abraços e até o próximo post.