BT

Async/Await - Efeitos sobre desempenho e outras armadilhas

| por Roopesh Shenoy Seguir 0 Seguidores , traduzido por Thomas Sant'Anna Seguir 0 Seguidores em 21 jan 2014. Tempo estimado de leitura: 2 minutos |

O artigo do MSDN intitulado "Melhores Práticas da Programação Assíncrona (Best Practices in Asynchronous Programming)" apresenta algumas considerações interessantes:

  • De preferência as tarefas async sobre métodos async sem valor de retorno (aqueles que retornam void). Isso não se aplica para tratamento de eventos. Keith Patton da Marker Metro também explica isso em detalhes;
  • Evite misturar código síncrono com assíncrono porque pode causar um risco maior de deadlocks, tratamento de erros mais complexos e bloqueio inesperado de threads de contexto;
  • Use o ConfigureAwait(false) para obter um desempenho melhor se o restante do código não precisa de informações do contexto original, pois o código restante continuará na threadpool do contexto. Isso ajuda a evitar deadlocks nos casos em que é obrigado a misturar código síncrono e assíncrono. Note que isso se aplica de maneira um pouco distinta quando tratamos o código no lado do servidor.

Chris Hurley, engenheiro de software da RedGate, explica o overhead de CPU de async-await e demonstra por meio da analise da execução de um código exemplo:

  • A invocação de um método que usa palavra chave "async" necessita da criação de uma máquina de estados e a construção de uma tarefa que contém o trabalho que deve ser executado, dessa forma é obtido o contexto de execução e de sincronização;
  • No exemplo analisado, 963 métodos do framework foram executados para inicializar um método async relativamente simples na primeira chamada;
  • O contexto é armazenado em cache para que as subsequentes chamadas consumam menos recursos;
  • Para os métodos que podem executar assincronamente no período muito curto de tempo, digamos 1 milisegundo, a ativação da chamada assíncrona bloqueia a thread por um período maior do que o necessário para sua computação. No exemplo usado, precisou de mais de 45 ms antes que a thread chamada fosse desbloqueada. Mesmo quando o código está dentro de um laço de repetição, embora as subsequentes chamadas exigissem menos tempo de processamento, a chamada da thread realmente não fornece nenhuma melhoria no desempenho;
  • Em resumo, evite uso de async/await para métodos muito curtos ou o uso de await em laços pequenos (coloque o laço inteiro em um método assíncrono).

Em outra notícia também apresentamos algumas outras pegadinhas comuns que ocorrem ao utilizar o async/await.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT