Hoje, vamos falar uns truques simples com strings no C#. Eu sei que pode ser demasiado óbvio e repetido pela internet fora, mas ainda assim quero dar a minha opinão sobre o assunto. Vamos a isto!
Imaginemos que temos uma List de qualquer type e vamos precisar dos seus valores separados por uma vírgula para serem enviados para uma stored procedure. O resultado desejado será, dada uma List de {1,2,3,4}, uma string neste formato: "1,2,3,4". Como vamos resolver este problema? Já vi e fiz múltiplas soluções para o problema, por isso vamos ordenar as possíveis soluções (na minha cabeça) da mais complexa para a mais simples. Primeiro, podemos fazer isto:
Vejam o quão complexo isto pode ser e o quão rapidamente se pode tornar insustentável. Quando repetido múltiplas vezes num projecto (imaginem ter isto repetido na vossa Camada de Acesso a Dados sempre que uma stored procedure precisa deste input), isto pode tornar-se doloroso. Claro que poderiamos extrair este comportamento para um extension method, mas como iremos ver isto não é necessário.
A nossa segunda abordagem, muito mais simples, utiliza todo o poder que LINQ nos traz. LINQ é uma daquelas tecnologias que eu adoro no .NET. Pode simplificar-vos muito a vida quando aplicado correctamente. Mas vamos ver como poderiamos fazê-lo neste caso:
Ainda assim, esta não é a nossa melhor solução. Vamos admitir, aquele uso do Aggregate e do Remove pode ser complicado de compreender à primeira vista. Na verdade, isto até fica pouco legível e temos que estar familiarizados com a forma como o Aggregate trabalha. Também veremos o quão horrivelmente lento é utilizar este método.
Vamos ver o próximo snippet:
Esta solução é simples, de fácil manutenção, fácil de compreender à primeira vista e, esperemos, com boa performance. Será mesmo? Vamos correr alguns testes e verificar! Para isso, preenchi a variável DocumentIDs com 10 000 000 ints, extraí cada uma das abordagens para um método e chamei-o 5 vezes envolvido num Stopwatch. Depois dividi o resultado em milisegundos por 5 para obter a média. Sim, eu sei que não é um benchmark de qualidade, mas serve para este exemplo.
Na altura dos testes eu tinha um Toshiba Satellite L40, Intel Pentium T2330 @ 1.6GHz e 2GB de RAM. Vamos ver os resultados:
Foreach com StringBuilder (Snippet 1): 4773 ms em média (Corri 5 vezes)
Não está mau de todo! Normalmente também nunca estaríamos a lidar com uma quantidade de dados desta natureza, mas é sempre bom ver como as várias opções se comportam sob pressão.
Aggregate com Remove (Snippet 2): acima de 1m:30s (Corri apenas uma vez. Não o deixei sequer acabar.)
Podemos ver que esta não é uma boa abordagem. Para começar, utilizar LINQ nesta situação é como matar moscas com canhões. Notem que estou a concatenar a string com o operador (+). Esta operação é extremamente lenta porque uma string é imutável e de cada vez uma nova string tem que ser instanciada. Portanto, esta não será a solução ideal.
String.Join (Snippet 3): 4670 ms em média (Corri 5 vezes)
Como podemos ver, o terceiro método é o mais rápido também. O primeiro também não lhe fica muito atrás, mas vamos manter as coisas simples. String.Join foi desenhado especificamente para estes casos, portanto vamos utilizar o que a framework nos oferece!
Se há uma lição que eu retiro deste tipo de situações é: não reinventes a roda quadrada. Todos nós o fazemos uma vez ou outra, é a nossa natureza como programadores, mas isso apenas importa se aprendermos algo com isso. Eu acredito que cada uma das abordagens tenha as suas vantagens e desvantagens. Por exemplo, consigo imaginar-me a utilizar a primeira abordagem para encapsular outro comportamente também quando o método fosse chamado, ou para formatar o output de outras formas mais personalizadas.
Sintam-se à vontade em partilhar outras formas de resolver o mesmo problema,
Obrigado pela leitura!
Links and references:
String.Join no MSDN
http://msdn.microsoft.com/en-us/library/57a79xd0.aspx
StringBuilder no MSDN
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx
Aggregate no MSDN
http://msdn.microsoft.com/en-us/library/bb548651.aspx
---------------------------------------------------------------------------------
Nota de rodapé:
Ao longo do tempo vou começar a actualizar o meu blogue para também incluir os posts em Português. Esta é a minha lingua materna e considero importante também chegar a quem não tem conhecimentos de inglês. No entanto não vou traduzir todos os termos para Português porque continuo a defender que será melhor procurá-los em Inglês, que é a linguagem geralmente aceite em fóruns internacionais. Qualquer termo que precisem explicado sintam-se à vontade para perguntar.
Imaginemos que temos uma List de qualquer type e vamos precisar dos seus valores separados por uma vírgula para serem enviados para uma stored procedure. O resultado desejado será, dada uma List de {1,2,3,4}, uma string neste formato: "1,2,3,4". Como vamos resolver este problema? Já vi e fiz múltiplas soluções para o problema, por isso vamos ordenar as possíveis soluções (na minha cabeça) da mais complexa para a mais simples. Primeiro, podemos fazer isto:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
List<int> DocumentIDs = new List<int>() {1,2,3,4,5,6,7,8,9}; | |
StringBuilder sb = new StringBuilder(); | |
foreach (int number in DocumentIDs) | |
sb.Append(",").Append(number); | |
sb = sb.Remove(0,1); | |
Console.WriteLine(sb.ToString()); |
Vejam o quão complexo isto pode ser e o quão rapidamente se pode tornar insustentável. Quando repetido múltiplas vezes num projecto (imaginem ter isto repetido na vossa Camada de Acesso a Dados sempre que uma stored procedure precisa deste input), isto pode tornar-se doloroso. Claro que poderiamos extrair este comportamento para um extension method, mas como iremos ver isto não é necessário.
A nossa segunda abordagem, muito mais simples, utiliza todo o poder que LINQ nos traz. LINQ é uma daquelas tecnologias que eu adoro no .NET. Pode simplificar-vos muito a vida quando aplicado correctamente. Mas vamos ver como poderiamos fazê-lo neste caso:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
List<int> DocumentIDs = new List<int>() {1,2,3,4,5,6,7,8,9}; | |
string s = DocumentIDs.Aggregate("", ((x, y)=> x + "," + y)).Remove(0,1); | |
Console.WriteLine(s); |
Ainda assim, esta não é a nossa melhor solução. Vamos admitir, aquele uso do Aggregate e do Remove pode ser complicado de compreender à primeira vista. Na verdade, isto até fica pouco legível e temos que estar familiarizados com a forma como o Aggregate trabalha. Também veremos o quão horrivelmente lento é utilizar este método.
Vamos ver o próximo snippet:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
List<int> DocumentIDs = new List<int>() {1,2,3,4,5,6,7,8,9}; | |
string MyString = string.Join(",", DocumentIDs); | |
Console.WriteLine (MyString); |
Esta solução é simples, de fácil manutenção, fácil de compreender à primeira vista e, esperemos, com boa performance. Será mesmo? Vamos correr alguns testes e verificar! Para isso, preenchi a variável DocumentIDs com 10 000 000 ints, extraí cada uma das abordagens para um método e chamei-o 5 vezes envolvido num Stopwatch. Depois dividi o resultado em milisegundos por 5 para obter a média. Sim, eu sei que não é um benchmark de qualidade, mas serve para este exemplo.
Na altura dos testes eu tinha um Toshiba Satellite L40, Intel Pentium T2330 @ 1.6GHz e 2GB de RAM. Vamos ver os resultados:
Foreach com StringBuilder (Snippet 1): 4773 ms em média (Corri 5 vezes)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
void Main() | |
{ | |
List<int> DocumentIDs = new List<int>(); | |
for (int i = 0; i < 10000000; i++) | |
DocumentIDs.Add(i); | |
Stopwatch sw = new Stopwatch(); | |
sw.Start(); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
sw.Stop(); | |
Console.WriteLine((sw.ElapsedMilliseconds / 5)); | |
} | |
void Test(List<int> DocumentIDs) | |
{ | |
StringBuilder sb = new StringBuilder(); | |
foreach (var element in DocumentIDs) | |
{ | |
sb.Append(",").Append(element); | |
} | |
string FinalString = sb.Remove(0,1).ToString(); | |
} |
Não está mau de todo! Normalmente também nunca estaríamos a lidar com uma quantidade de dados desta natureza, mas é sempre bom ver como as várias opções se comportam sob pressão.
Aggregate com Remove (Snippet 2): acima de 1m:30s (Corri apenas uma vez. Não o deixei sequer acabar.)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
void Main() | |
{ | |
List<int> DocumentIDs = new List<int>(); | |
for (int i = 0; i < 10000000; i++) | |
DocumentIDs.Add(i); | |
Stopwatch sw = new Stopwatch(); | |
sw.Start(); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
sw.Stop(); | |
(sw.ElapsedMilliseconds / 5).Dump(); | |
} | |
void Test(List<int> DocumentIDs) | |
{ | |
string s = DocumentIDs.Aggregate("", ((x, y)=> x + "," + y)).Remove(0,1); | |
} |
String.Join (Snippet 3): 4670 ms em média (Corri 5 vezes)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
void Main() | |
{ | |
List<int> DocumentIDs = new List<int>(); | |
for (int i = 0; i < 10000000; i++) | |
DocumentIDs.Add(i); | |
Stopwatch sw = new Stopwatch(); | |
sw.Start(); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
Test(DocumentIDs); | |
sw.Stop(); | |
Console.WriteLine(sw.ElapsedMilliseconds / 5); | |
} | |
void Test(List<int> DocumentIDs) | |
{ | |
string s2 = string.Join(",", DocumentIDs); | |
} |
Como podemos ver, o terceiro método é o mais rápido também. O primeiro também não lhe fica muito atrás, mas vamos manter as coisas simples. String.Join foi desenhado especificamente para estes casos, portanto vamos utilizar o que a framework nos oferece!
Se há uma lição que eu retiro deste tipo de situações é: não reinventes a roda quadrada. Todos nós o fazemos uma vez ou outra, é a nossa natureza como programadores, mas isso apenas importa se aprendermos algo com isso. Eu acredito que cada uma das abordagens tenha as suas vantagens e desvantagens. Por exemplo, consigo imaginar-me a utilizar a primeira abordagem para encapsular outro comportamente também quando o método fosse chamado, ou para formatar o output de outras formas mais personalizadas.
Sintam-se à vontade em partilhar outras formas de resolver o mesmo problema,
Obrigado pela leitura!
Links and references:
String.Join no MSDN
http://msdn.microsoft.com/en-us/library/57a79xd0.aspx
StringBuilder no MSDN
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx
Aggregate no MSDN
http://msdn.microsoft.com/en-us/library/bb548651.aspx
---------------------------------------------------------------------------------
Nota de rodapé:
Ao longo do tempo vou começar a actualizar o meu blogue para também incluir os posts em Português. Esta é a minha lingua materna e considero importante também chegar a quem não tem conhecimentos de inglês. No entanto não vou traduzir todos os termos para Português porque continuo a defender que será melhor procurá-los em Inglês, que é a linguagem geralmente aceite em fóruns internacionais. Qualquer termo que precisem explicado sintam-se à vontade para perguntar.
Comments
Post a Comment