Existem cenários em que SET NOCOUNT ON é obrigatório. Ao projetar uma camada intermediária de alto desempenho com base no processamento assíncrono, aproveitando o pool de threads por meio dos métodos BeginExecuteXXX do SqlClient, há um problema muito sério com as contagens de linhas. Os métodos BeginExecute são concluídos assim que o primeiro pacote de resposta é retornado pelo servidor. Mas quando um EndExecuteXXX é invocado, isso é concluído em solicitações que não são de consulta quando a chamada é concluída. Cada resposta de contagem de linhas é uma resposta. Ao processar até mesmo procedimentos moderadamente complexos, a contagem da primeira linha pode retornar em 5 a 10 ms, enquanto a chamada é concluída em 300 a 500 ms. Em vez de ter a solicitação assíncrona enviada de volta após 500 ms, ela chama de volta após 5 ms e, em seguida, o retorno de chamada é bloqueado no EndExecuteXXX por 495 ms. O resultado é que as chamadas assíncronas são concluídas prematuramente e bloqueiam um thread do pool de threads nas chamadas EndExecuteNonQuery. Isso leva à fome do ThreadPool. Já vi sistemas de alto desempenho melhorarem a taxa de transferência de centenas de chamadas por segundo para milhares de chamadas por segundo simplesmente adicionando o SET NOCOUNT ON, em cenários específicos.

Dado que, para processamento de camada intermediária de alta escala/alto rendimento, as chamadas assíncronas são o único caminho a percorrer, o NOCOUNT é praticamente um requisito obrigatório.