Considérons cette méthode asynchrone très simple:
static async Task myMethodAsync()
{
await Task.Delay(500);
}
Lorsque je compile ceci avec VS2013 (pré-compilateur Roslyn), la machine à états générée est une structure.
private struct <myMethodAsync>d__0 : IAsyncStateMachine
{
...
void IAsyncStateMachine.MoveNext()
{
...
}
}
Lorsque je le compile avec VS2015 (Roslyn), le code généré est le suivant:
private sealed class <myMethodAsync>d__1 : IAsyncStateMachine
{
...
void IAsyncStateMachine.MoveNext()
{
...
}
}
Comme vous pouvez le voir, Roslyn génère une classe (et non une structure). Si je me souviens bien, les premières implémentations du support async / await dans l'ancien compilateur (CTP2012 je suppose) ont également généré des classes, puis elles ont été modifiées en struct pour des raisons de performances. (dans certains cas , vous pouvez éviter complètement la boxe et l' allocation des tas ...) (Voir ce )
Est-ce que quelqu'un sait pourquoi cela a été changé à nouveau à Roslyn? (Je n'ai aucun problème à ce sujet, je sais que ce changement est transparent et ne change le comportement d'aucun code, je suis juste curieux)
Éditer:
La réponse de @Damien_The_Unbeliever (et le code source :)) à mon humble avis explique tout. Le comportement décrit de Roslyn s'applique uniquement à la version de débogage (et cela est nécessaire en raison de la limitation CLR mentionnée dans le commentaire). Dans Release, il génère également une structure (avec tous les avantages de cela ..). Cela semble donc être une solution très intelligente pour prendre en charge à la fois Edit et Continue et de meilleures performances en production. Des choses intéressantes, merci à tous ceux qui ont participé!
async
les méthodes ont presque toujours un vrai point asynchrone - unawait
qui donne le contrôle, ce qui exigerait de toute façon que la structure soit encadrée. Je crois que les structs soulageraient uniquement la pression de la mémoire pour lesasync
méthodes qui s'exécutaient de manière synchrone.