FSharp.Core non optimisé?

Question

J'ai récemment inspecté les performances d'une application F # et en explorant le CIL, j'ai découvert que FSharp.Core (pour .NET v4.0) contient plusieurs instructions nop, de nombreuses variables inutilisées et des variables qui ne sont écrites que/lire une fois via des séquences d'instructions stloc/ldloc. J'ai étudié les causes possibles et j'ai remarqué que même en mode release, les assemblys F # incluent la directive --debug: pdbonly et il n'y a aucun moyen de désactiver cela et de passer à --debug- à partir de l'interface utilisateur du projet.
Je me demande s'il y avait un choix spécifique pour les paramètres de compilation de FSharp.Core et si c'était le cas. Sinon, est-il légitime d'attendre une version entièrement optimisée du runtime?

Answer 1

Il semble que les commentaires sur la question ont déjà répondu à environ 90% de cette question; de les réitérer:

• presque tous les binaires de libération dans l'univers est compilé avec --debug: pdbonly
• même si le code IL est sous-optimal, cela peut ne pas avoir d'impact dans le monde réel en raison de la JIT optimisant loin

il y a, bien sûr, toutes sortes de façons le compilateur F # pourrait être potentiellement émettre un meilleur code (ce qui est probablement vrai de chaque compilateur); Si vous profilez votre application et remarquez quelque chose de mauvais (par exemple un gros écart par rapport à un code comparable de C#), vous pouvez informer l'équipe F # en envoyant des fsbugs. Mais mesurez d'abord.

Answer 2

Sinon, est-il légitime d'attendre une version entièrement optimisée du runtime?

Les modifications que vous suggérez ne peuvent raisonnablement pas être considérées comme des optimisations. Les deux sont inoffensifs et seront compilés par la VM. ISTR, la mutation est utilisée pour remplacer l'empilement car la machine virtuelle basée sur la pile peut empiler le débordement. Donc c'est F # qui fonctionne correctement autour d'un bug dans le CLR.