Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Vous et le Framewok, résultat du sondage

Bien que la collecte des données continue, il est d'ores et déjà possible de dresser un premier bilan suite au sondage que je vous proposais en début de semaine "Vous et le Framework .NET".

En quatre questions qui n'ont pas pour ambition de cerner tous les cas possibles, on peut malgré tout voir des tendances, des envies, se dessiner. Je vous avais promis de vous livrer les résultats pour que votre participation à ce petit sondage soit remerciée par l'accès aux données, les voici (pour des raisons de mise en page ici j'ai préféré insérer une image que refaire les tableaux avec une CSS compatible avec le thème du blog) :

 

Constatations

je ne vais pas me livrer à de grandes analyses, vous savez lire les chiffres comme moi. On peut en revanche relever certaines choses intéressantes :

  • Le framework 3.5 semble largement adopté en production (58%)
  • Le framework 1.x n'a visiblement servi qu'aux tests et aux périodes d'apprentissage, voire a été "sauté" par une majorité d'utilisateurs puisque vous êtes 0% à déclarer l'utiliser en production ! Cela peut aussi signifier que les mises à jour du framework en production sont bien plus aisées que le "DLL Hell" de Win32 et que vous n'hésitez pas à faire évoluer les machines en production au rythme des grands changements du Framework. En tout cas, pas de 1.x en production, c'est une info peu surprenante mais maintenant on le sait :-)
  • Le Compact Framework est utilisé en production par 16% d'entre vous. Je suis surpris par ce résultat car je n'ai encore croisé aucun projet de ce type chez aucun de mes clients. Je ne sais pas tout et ne vois pas tout, c'est une évidence dont, rassurez-vous j'ai parfaitement conscience de longue date, mais une technologie .NET utilisée par presque 1/5 des développeurs que je n'aurai jamais vue nulle part en production ça me bluffe. En même temps je trouve ça particulièrement encourageant, comme vous je mise beaucoup sur l'avènement des technos mobiles. Vous êtes d'ailleurs 26% à déclarer que vous allez utiliser le Compact Framework dans les 12 mois à venir. J'aurai ainsi plus de chance de voir de telles réalisations en clientèle ! :-) Tout cela se réalisera-t-il oui bien s'agit-il d'un désir ? C'est toujours la délicate question de l'interprétation de ce type de question dans un sondage. Je me garderais de jouer aux experts et de proposer une réponse. Nous verrons d'ici un an !
  • Le Roi LINQ ! On peut l'appeler comme ça à la vue de vos réponses. 53% d'adoption pour LINQ to Objects c'est un score qui démontre la rapidité de pénétration de cette technologie et qui donne raison à tout le bien que j'en dis depuis le début ! Vous êtes même 84% à déclarer que vous utiliserez LINQ to Objects en production sous 6 mois. Génial. C'est vrai qu'une fois qu'on y a goûté on peut difficilement s'en passer. Si j'ai pu modestement y être pour un tout petit quelque chose dans l'intérêt que vous portez à cette technologie, j'en suis très content.
  • On remarque que LINQ to XML connaît le même succès, même s'il reste moins utilisé (47%) et que les prévisions d'utilisation sont moins spectaculaires (58%). Il reste donc des efforts d'information à fournir ! XML étant partout nous devrions avoir presque 100% d'utilisation de LINQ to XML qui simplifie grandement toutes les opérations sur ces sources de données. Cela confirme la place que je consacre à LINQ to XML dans mon prochain ouvrage (plus de news à ce sujet d'ici quelques semaines).
  • LINQ to SQL connaît un succès plutôt étonnant pour un OR/M (37% en production !) et vous êtes mêmes 47% à déclarer que vous utiliserez cette techno dans les prochains mois. Il va falloir vous calmer un peu sur LINQ to SQL. En effet, il fait un peu doublon avec LINQ to Entities tout en étant bien plus limité. De ce que je sais, Microsoft a décidé d'arrêter les frais sur LINQ to SQL au profit de LINQ to Entities. LINQ to SQL continuera d'exister mais n'espérez pas trop qu'il se charge de grosses nouveautés pour le faire ressembler à LINQ to Entities... Migrer dès maintenant vers l'Entity Framework dès maintenant et ne débutez plus de nouveaux projets en LINQ to SQL, c'est mon conseil du jour...
  • LINQ to Datasets est le parent pauvre du sondage : 0% en production ! Le pauvre...  Il y a forcément une raison derrière cet état de fait que le sondage ne peut pas percer. Le Dataset est-il de moins en moins utilisé ? Les techniques d'accès aux objets via LINQ et les collections d'objets ont-elles balayé les anciennes coutumes plus proche du SQL et des représentations en tables ? Vous êtes malgré tout 53% à déclarer que vous utiliserez cette techno dans les 6 mois. Renversement étonnant. Les commentaires de ce billet sont ouverts, n'hésitez pas à vous exprimer !
  • LINQ to Entities fait mouche, 11% en production, déjà un joli score pour une techno très récente et 68% de déclaration d'utilisation sous 6 mois. On voit à quel point l'objectivation des données via l'Entity Framework répond à une réelle attente. Continuez, LINQ to Entities c'est l'avenir, de façon bien plus pragmatique que d'espérer l'avènement des bases de données objet qui n'arrivera probablement jamais maintenant (en dehors de quelques succès d'estimes comme DB4O ou O2 dont l'utilisation en production est marginale).
  • Le Workflow (WF) est utilisé par 5% d'entre vous et 16% prévoient de s'en servir. C'est vraiment un beau score pour une techno très peu mise en avant, sur laquelle on trouve peu de ressources et d'exemples. Mais que ceux qui se lancent dans cette voie se rassurent, WF s'imposera avec le temps. Il faut juste laisser un peu de temps aux développeurs pour digérer toutes les nouveautés de .NET qui sont toutes aussi essentielles les unes que les autres. Hélas les journées ne comptent que 24h !
  • WPF est adopté par 21% d'entre vous. C'est encore un peu faible, mais vous êtes 53% à déclarer vouloir l'utiliser en production dans les 6 mois. Adios WinForms ? Très certainement, à termes. Reste à maîtriser WPF, Blend, Design et à trouver un copain ou une copine infographiste. Car si faire du WPF c'est juste poser des composants sur une fiche et utiliser des thèmes "tout fait", c'est en utiliser 10% des possibilités, autant rester en WinForms... Je ne doute pas un instant que vous l'avez compris et que vous avez déjà passé des annonces pour recruter un graphiste ! :-)
  • Xbap, 5% en production, 16% d'intention. Que dire de plus. Microsoft même ne pousse pas / plus cette techno pourtant séduisante à plus d'un titre. Mais cela se comprend. Xbap ce sont les possibilités graphiques de WPF avec les limitations du Web et l'obligation d'une cible Internet Explorer. A ce jeu là Silverlight tire son épingle du jeu. Si les limites du Web sont les mêmes, et même si son support de WPF et du framework est plus limité que Xbap, Silverlight offre la portabilité Mac/Linux et ne se limite pas à IE. Xbap restera vraisemblablement une techno de niche, répondant à des besoins très ponctuels. Ailleurs Silverlight sera préféré.
  • Avec 32% en production Silverlight confirme ce que je disais. Il faut dire que la sortie de la V2 et de tous ces avantages secoue le cocotier ! 53% d'entre vous déclare qu'ils vont utiliser Silverlight dans les 6 mois. C'est une adoption massive qui semble donc s'annoncer. Je pense d'ailleurs que c'est par Silverlight que WPF s'imposera et séduira. C'est ce qui semble se produire. Les retombées WPF desktop auront lieu plus tard, lorsque Windows 7 aura pris la place que Vista aurait du occuper sur le marché.
  • WCF est bien installé (53%) et stable (53%) ! La communication prend une place importante dans les développements, ce qui est logique et dans l'air du temps.
  • Reste les "autres" technologies. J'avais laissé ouvert cette possibilité car je sais bien que certaines personnes n'aiment pas se sentir coincer par un questionnaire fermé... Parmi celles en production (les technos par les personnes!) on notera, par force WinForms, ASP.NET qui ne faisait pas partie de mon sondage, la techno est moins récente que celles que j'avais choisi de sonder, ASP.NET Ajax et de façon amusante "aucune et N/A". Dans les intentions sous 6 mois on voir revenir ASP.NET Ajax, ce qui semble normal et une personne qui indique ASP.NET MVC (Sylvain tu es démarqué !).

Conclusion

Il n'y a rien à conclure, je ne vous jouerai pas le jeu des sondeurs avant les élections qui se plantent à chaque fois. A vous de conclure ! J'ai juste profité de quelques constats pour discuter un peu. Vos commentaires sont les bienvenus !

C# - Les optimisations du compilateur dans le cas du tail-calling

Les optimisations du compilateurs C# ne sont pas un sujet de discussion très courant, en tout cas on voit très nettement que le fait d'avoir quitté l'environnement Win32 pour l'environnement managé de .NET a fait changer certaines obsessions des codeurs... Ce n'est pas pour autant que le sujet a moins d'intérêt ! Nous allons voir cela au travers d'une optimisation particulière appelée "tail-calling" (appel de queue, mais je n'ai pas trouvé de traduction française, si quelqu'un la connaît, qu'il laisse un commentaire au billet).

Principe

On appelle "tail-calling" un mécanisme d'optimisation du compilateur qui permet d'économiser les instructions exécutées en même temps que des accès à la pile. Les circonstances dans lesquelles le compilateur peut utiliser cette optimisation sont celles où une méthode se termine par l'appel d'une autre, d'où le nom de tail-calling (appel de queue).

Prenons l'exemple suivant :

static public void Main()
{
    Go();
}
 
static public void Go()
{
    Première();
    Seconde();
    Troisième();
}
 
static public void Troisième()
{
}

Dans cet exemple le compilateur peut transformer l'appel de Troisième() en un appel de queue (tail-calling). Pour mieux comprendre regardons l'état de la pile au moment de l'exécution de Seconde()  : Seconde()-Go()-Main()

Quand Troisième() est exécutée il devient possible, au lieu d'allouer un nouvel emplacement sur la pile pour cette méthode, de simplement remplacer l'entrée de Go() par Troisième(). La pile ressemble alors à Troisième()-Main().

Quand Troisième() se terminera elle passera l'exécution à Main() au lieu de transférer le trait à Seconde() qui immédiatement devra le transférer à Main().

C'est une optimisation assez simple qui, cumulée tout au long d'une application, et ajoutée aux autres optimisations, permet de rendre le code exécutable plus efficace.

Quand l'optimisation est-elle effectuée ?

La question est alors de savoir quand le compilateur décide d'appliquer l'optimisation de tail-calling. Mais dans un premier temps il faut se demander de quel compilateur nous parlons.... Il y existe en effet deux compilateurs dans .NET, le premier prend le code source pour le compiler en IL alors que le second, le JIT, utilisera ce code IL pour créer le code natif. La compilation en IL peut éventuellement placer certains indices qui permettront de mieux repérer les cas où le tail-calling est applicable mais c'est bien entendu dans le JIT que cette optimisation s'effectue.

Il existe de nombreuses règles permettant au JIT de décider s'il peut ou non effectuer l'optimisation. Voici un exemple de règles qui font qu'il n'est pas possible d'utiliser le tail-calling (par force cette liste peut varier d'une implémentation à l'autre du JIT) :

  • L'appelant ne retourne pas directement après l'appel;
  • Il y a une incompatibilité des arguments passés sur la pile entre l'appelant et l'appelé ce qui imposerait une modification des arguments pour appliquer le tail-calling;
  • L'appelant et l'appelé n'ont pas le même type de retour (données de type différents, void);
  • L'appel est est transformé en inline, l'inlining étant plus efficace que le tail-calling et ouvrant la voie à d'autres optimisations;
  • La sécurité interdit ponctuellement d'utiliser l'optimisation;
  • Le compilateur, le profiler, la configuration ont coupé les optimisations du JIT.

Pour voir la liste complète des règles, jetez un oeil à ce post.

Intérêt de connaitre cette optimisation ?

Normalement les optimisations du JIT ne sont pas un sujet intéressant au premier chef le développeur. D'abord parce qu'un environnement managé comme .NET fait qu'à la limite ce sont les optimisations du code IL qui regarde directement le développeur et beaucoup moins la compilation native qui peut varier d'une plateforme à l'autre pour une même application. Ensuite il n'est pas forcément judicieux de se reposer sur les optimisations du JIT puisque, justement, ce dernier peut être différent sans que l'application ne le sache.

Qui s'intéresse à l'optimisation du tail-calling alors ? Si vous écrivez un profiler c'est une information intéressante, mais on n'écrit pas un tel outil tous les jours... Mais l'information est intéressante lorsque vous déboguez une application car vous pouvez vous trouver face à une pile d'appel qui vous semble "bizarre" ou "défaillante" car il lui manque l'une des méthodes appelées !

Et c'est là que savoir qu'il ne faut pas chercher dans cette direction pour trouver le bug peut vous faire gagner beaucoup de temps... Savoir reconnaître l'optimisation de tail-calling évite ainsi de s'arracher les cheveux dans une session de debug un peu compliquée si on tombe en plus sur un pile d'appel optimisée. Un bon debug consiste à ne pas chercher là où ça ne sert à rien (ou à chercher là où c'est utile, mais c'est parfois plus difficile à déterminer !), alors rappelez-vous du tail-calling !

Et stay tuned !

nota: le présent billet est basé sur un post de l'excellent blog ASP.NET Debugging