Runtime: [mscorlib] Déplacement d'un plus grand nombre de fonctions String vers du code managé

Créé le 1 mai 2016 · 3Commentaires · Source: dotnet/runtime

Dans l'état actuel des choses, de nombreuses fonctions de chaîne de « haut niveau » comme IndexOf , LastIndexOf , Replace etc. sont implémentées nativement alors qu'elles pourraient être écrites en code managé. J'ai remarqué que cela avait été fait avec l'une des surcharges string.Replace dans f007485, alors peut-être qu'il serait bon de le faire pour rendre le code plus accessible aux nouveaux arrivants, s'ils ne sont pas familiers avec la façon dont le code C++ correspond à C#.

area-System.Runtime enhancement untriaged

Source

jamesqo

👍1

Commentaire le plus utile

Nous avons examiné cela dans le passé et déplacé tout ce qui pouvait être déplacé sans perte de performances significative. Déplacer davantage dépend d'avoir de bonnes optimisations gérées pour toutes les architectures coreclr.

Il est logique de ne considérer qu'une fois que RyuJIT ou un meilleur codegen est disponible pour toutes les architectures sur lesquelles coreclr s'exécute (x86, x64, arm, arm64).

BTW : les implémentations gérées de toutes les méthodes de chaîne sont disponibles dans le référentiel corert.

jkotas le 1 mai 2016

👍3

Tous les 3 commentaires

Il est logique de ne considérer qu'une fois que RyuJIT ou un meilleur codegen est disponible pour toutes les architectures sur lesquelles coreclr s'exécute (x86, x64, arm, arm64).

BTW : les implémentations gérées de toutes les méthodes de chaîne sont disponibles dans le référentiel corert.

jkotas le 1 mai 2016

👍3

@jkotas Ah, c'est pourquoi les implémentations dans le référentiel corert sont gérées ; puisqu'il est compilé AOT et optimisé par le compilateur C++, ils obtiennent un meilleur codegen que l'implémentation JIT qui est toujours un travail en cours pour certaines des plates-formes que vous mentionnez (arm, arm64). Merci d'avoir éclairci cela, c'est logique maintenant.

jamesqo le 1 mai 2016

Fermeture à partir de la réponse de @jkotas ci-dessus, il n'y a plus rien à faire ici. @jamesqo n'hésitez pas à rouvrir si vous pensez le contraire.