Limpar strings é uma tarefa comum em nossas aplicações. Entretanto, .NET torna fácil cometer erros de implementação que levam a alocações em demasia e, consequentemente, a muitas ocorrências de garbage collection.
Este post mostra como aliviar essa pressão.
Começaremos utilizando o mesmo mecanismo de comparação que utilizamos no post anterior.
Ponto de partida
Mais uma vez, vamos começar com um código que está em produção.
public static string RemoverCaracteres(this string valor, params string[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
foreach (var s in caract)
{
valor = valor.Replace(s, "");
}
return valor;
}
Cada chamada ao método Replace aloca uma nova string na memória. Logo, aumenta a pressão pela intervenção do GC.
Vejamos o resultado (1_000_000 de execuções sobre um RG, removendo os caracteres ‘/’, ‘.’, ‘-‘):
Obviamente, há um milhão de strings novas sendo geradas, pelo menos. Logo, é natural que o GC entre em atuação.
A saída nem sempre é StringBuilder
A primeira ideia foi substituir ingenuamente a string por um StringBuilder antes de fazer os replaces.
public static string RemoverCaracteres(this string valor, params string[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
var sb = new StringBuilder(valor);
foreach (var s in caract)
{
sb.Replace(s, "");
}
return sb.ToString();
}
Infelizmente, o resultado não foi o mais animador.
Vamos usar chars?
Um problema, na implementação original é que ela propõe (pelo nome) a remover caracteres. Entretanto, por alguma razão que desconheço, ela aceita uma lista de strings. Vamos adotar uma abordagem mais simples removendo apenas caracteres, reconstruindo strings quando possível.
public static string RemoverCaracteres(this string valor, params char[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
var sb = new StringBuilder(valor.Length);
for (var i = 0; i < valor.Length; i++)
{
bool adicionar = true;
for (var j = 0; j < caract.Length; j++)
{
if (caract[j] == valor[i])
{
adicionar = false;
break;
}
}
if (adicionar)
{
sb.Append(valor[i]);
}
}
return sb.ToString();
}
Resultado:
Bem melhor.
Reaproveitando instâncias de StringBuilder
Há algum tempo, compartilhamos uma técnica usada pelo time do Roslyn para salvar memória (e execuções do GC) salvando algumas instâncias de Stringbuilder. Vamos adotar a mesma técnica aqui.
public static string RemoverCaracteres(this string valor, params char[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
var sb = PooledStringBuilder.GetInstance();
for (var i = 0; i < valor.Length; i++)
{
bool adicionar = true;
for (var j = 0; j < caract.Length; j++)
{
if (caract[j] == valor[i])
{
adicionar = false;
break;
}
}
if (adicionar)
{
sb.Builder.Append(valor[i]);
}
}
return sb.ToStringAndFree();
}
Resultado:
Melhoramos, mas, nem tanto. O fato do GC ser executado não implica, necessariamente, em penalidade de performance. O GC é muito eficiente para desalocar objetos com vida muito curta. Mesmo assim, a melhoria se justifica quando pensamos na aplicação como um todo.
Vamos usar foreach
Sempre que temos que percorrer um vetor, fazemos testes com for e com foreach. Em muitos casos, foreach é mais rápido. Vejamos:
public static string RemoverCaracteres(this string valor, params char[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
var sb = PooledStringBuilder.GetInstance();
foreach (var c in valor)
{
bool adicionar = true;
for (var j = 0; j < caract.Length; j++)
{
if (caract[j] == c)
{
adicionar = false;
break;
}
}
if (adicionar)
{
sb.Builder.Append(c);
}
}
return sb.ToStringAndFree();
}
Resultado:
Unsafe!
Eis uma estratégia que não recomendamos. Geralmente, adotar unsafe deve ser uma alternativa apenas em cenários onde performance é um aspecto realmente crítico. De qualquer forma…
public static unsafe string RemoverCaracteres(this string valor, params char[] caract)
{
if (String.IsNullOrWhiteSpace(valor))
{
return String.Empty;
}
char* resultado = stackalloc char[valor.Length];
char* current = resultado;
foreach (var c in valor)
{
bool adicionar = true;
foreach (var o in caract)
{
if (o == c)
{
adicionar = false;
break;
}
}
if (adicionar)
{
*current++ = c ;
}
}
return new string(resultado, 0, (int)(current - resultado)); ;
}
Resultado:
UPDATE: Não é necessário mais usar unsafe para usar stackalloc
Fazendo comparações mais precisas
Quando diferentes execuções retornam valores muito diferentes (é o caso do código que estamos tratando nesse post), devemos recorrer a mecanismos de medida mais confiáveis.
Para testar performance de algoritmos, recomendo fortemente a adoção do BenchmarkDotNet.
public class Program
{
static void Main(string[] args)
{
var summary = BenchmarkRunner.Run<Program>();
}
[Benchmark]
public void NoOptimizations() =>
Original.RemoverCaracteres("00.816.794/0001-66", ".", "/", "-");
[Benchmark]
public void UsingStringBuilder() =>
Version1.RemoverCaracteres("00.816.794/0001-66", ".", "/", "-");
[Benchmark]
public void UsingStringBuilderWithChars() =>
Version2.RemoverCaracteres("00.816.794/0001-66", '.', '/', '-');
[Benchmark]
public void UsingPooledStringBuilderWithChars() =>
Version3.RemoverCaracteres("00.816.794/0001-66", '.', '/', '-');
[Benchmark]
public void UsingPooledStringBuilderWithCharsAndForEach() =>
Version4.RemoverCaracteres("00.816.794/0001-66", '.', '/', '-');
[Benchmark]
public void Unsafe() =>
Version5.RemoverCaracteres("00.816.794/0001-66", '.', '/', '-');
}
Eis os resultados:
Frequency=2835935 Hz, Resolution=352.6174 ns, Timer=TSC
.NET Core SDK=2.1.104
[Host] : .NET Core 2.0.6 (CoreCLR 4.6.26212.01, CoreFX 4.6.26212.01), 64bit RyuJIT
DefaultJob : .NET Core 2.0.6 (CoreCLR 4.6.26212.01, CoreFX 4.6.26212.01), 64bit RyuJIT
Method | Mean | Error | StdDev |
-------------------------------------------- |----------:|----------:|-----------:|
NoOptimizations | 289.76 ns | 5.8188 ns | 13.1341 ns |
UsingStringBuilder | 477.36 ns | 9.2958 ns | 11.7562 ns |
UsingStringBuilderWithChars | 115.18 ns | 0.8101 ns | 0.7182 ns |
UsingPooledStringBuilderWithChars | 101.00 ns | 1.6023 ns | 1.4988 ns |
UsingPooledStringBuilderWithCharsAndForEach | 97.72 ns | 1.9388 ns | 2.3080 ns |
Unsafe | 63.11 ns | 1.4262 ns | 2.1347 ns |
Resumindo
Mais uma vez, o GC exerceu influência na performance. Entretanto, como vimos, ele não é definitivo. Unsafe é sempre uma opção para cenários extremos, mas o código fica menos legível e o ganho pode não se justificar.
De qualquer forma, no fim do dia, ganhamos 80 coletas do GC e melhoramos a performance em mais de 400%.
Lição mais importante: MEDIR, MEDIR, MEDIR
