Embora eu realmente entenda as sérias implicações de brincar com essa função (ou pelo menos é o que eu acho), eu não consigo entender por que isso está se tornando uma daquelas coisas que programadores respeitáveis ​​jamais usariam, mesmo aqueles que nem sabem Para que isso serve.

Digamos que eu esteja desenvolvendo um aplicativo em que o uso da memória varia muito, dependendo do que o usuário está fazendo. O ciclo de vida da aplicação pode ser dividido em duas etapas principais: edição e processamento em tempo real. Durante o estágio de edição, suponha que bilhões ou até trilhões de objetos sejam criados; alguns deles pequenos e alguns deles não, alguns podem ter finalizadores e outros não, e supor que suas vidas variam de poucos milissegundos a longas horas. Em seguida, o usuário decide mudar para o estágio em tempo real. Neste ponto, suponha que o desempenho desempenhe um papel fundamental e que a menor alteração no fluxo do programa possa trazer conseqüências catastróficas. A criação de objetos é então reduzida ao mínimo possível usando pools de objetos e o tal, mas, em seguida, o GC entra inesperadamente e joga tudo fora, e alguém morre.

A pergunta: Neste caso, não seria sensato chamar o GC.Collect () antes de entrar no segundo estágio?

Afinal, esses dois estágios nunca se sobrepõem no tempo um com o outro e toda a otimização e estatísticas que o GC poderia ter reunido seriam de pouca utilidade aqui ...

Nota: Como alguns de vocês apontaram, o .NET pode não ser a melhor plataforma para um aplicativo como este, mas isso está além do escopo desta questão. A intenção é esclarecer se uma chamada GC.Collect () pode melhorar o comportamento / desempenho geral de um aplicativo ou não. Todos concordamos que as circunstâncias sob as quais você faria tal coisa são extremamente raras, mas, novamente, o GC tenta adivinhar e faz isso perfeitamente na maioria das vezes, mas ainda se trata de adivinhação.

Obrigado.