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

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
0 Comentários
Inline Feedbacks
View all comments

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas a gerar mais resultados através da tecnologia.

SOLUÇÕES EXIMIACO

ESTRATÉGIA & EXECUÇÃO EM TI

Simplificamos, potencializamos 
aceleramos resultados usando a tecnologia do jeito certo.

COMO PODEMOS LHE AJUDAR?

Vamos marcar uma conversa para que possamos entender melhor sua situação e juntos avaliar de que forma a tecnologia pode trazer mais resultados para o seu negócio.

COMO PODEMOS LHE AJUDAR?

Vamos marcar uma conversa para que possamos entender melhor sua situação e juntos avaliar de que forma a tecnologia pode trazer mais resultados para o seu negócio.

+55 51 3049-7890
[email protected]

+55 51 3049-7890 |  [email protected]

0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.