Premièrement, (IMO) comparer avec Python n'a presque pas de sens. Seule la comparaison avec Objective-C est significative.
- Comment un nouveau langage de programmation peut-il être tellement plus rapide?
Objective-C est un langage lent. (Seule la partie C est rapide, mais c'est parce que c'est C) Cela n'a jamais été extrêmement rapide. C'était juste assez rapide pour leur objectif (Apple), et plus rapide que leurs anciennes versions. Et c'était lent parce que ...
- Objective-C résulte-t-il d'un mauvais compilateur ou existe-t-il quelque chose de moins efficace dans Objective-C que Swift?
Objective-C garantissait la distribution dynamique de chaque méthode. Pas d'envoi statique du tout. Cela a rendu impossible l'optimisation d'un programme Objective-C. Eh bien, peut-être que la technologie JIT peut être utile, mais AFAIK, Apple déteste vraiment les caractéristiques de performances imprévisibles et la durée de vie des objets. Je ne pense pas qu'ils avaient adopté des trucs JIT. Swift ne dispose pas d’une telle garantie d’expédition dynamique, à moins que vous ne mettiez un attribut spécial pour la compatibilité Objective-C.
- Comment expliqueriez-vous une augmentation de performance de 40%? Je comprends que le contrôle de référence automatisé / récupération de place peut générer des coûts supplémentaires, mais c’est tout?
GC ou RC n'a pas d'importance ici. Swift emploie également principalement RC. Il n'y a pas de GC, et ne le fera pas à moins d'un saut architectural énorme en matière de technologie GC. (IMO, c'est pour toujours) Je pense que Swift a beaucoup plus de place pour l'optimisation statique. Les algorithmes de chiffrement particulièrement bas, car ils reposent généralement sur des calculs numériques énormes, ce qui représente un gain énorme pour les langages d'expédition statiques.
En fait, j'ai été surpris car 40% semble trop petit. Je m'attendais à beaucoup plus. Quoi qu'il en soit, ceci est la version initiale, et je pense que l'optimisation n'était pas la préoccupation principale. Swift n'est même pas complet! Ils vont le rendre meilleur.
Mise à jour
Certains n'arrêtent pas de me faire dire que la technologie du GC est supérieure. Bien que les éléments ci-dessous puissent être discutés, et juste mon opinion très biaisée, mais je pense que je dois dire pour éviter cet argument inutile.
Je sais ce que sont les GC conservateurs / traçage / génération / incrémental / parallèle / temps réel et en quoi ils sont différents. Je pense que la plupart des lecteurs le savent aussi déjà. Je conviens également que GC est très utile dans certains domaines et affiche également un débit élevé dans certains cas.
Quoi qu'il en soit, je soupçonne que le débit du GC est toujours supérieur au RC. La majeure partie des frais généraux de RC provient de l'opération de décompte et du verrouillage pour protéger la variable du nombre de ref. Et la mise en œuvre de la RC fournit généralement un moyen d’éviter les opérations de comptage. En Objective-C, il y a __unsafe_unretained
et en Swift (bien que ce ne soit toujours pas clair pour moi) des unowned
trucs. Si le coût de l'opération de recomptage n'est pas acceptable, vous pouvez essayer de les exclure de manière sélective en utilisant les mécanismes. Théoriquement, nous pouvons simuler un scénario de propriété presque unique en utilisant des références non conservées de manière très agressive afin d'éviter les frais généraux liés aux RC. Je pense aussi que le compilateur peut éliminer automatiquement certaines opérations évidentes et inutiles de la télécommande.
Contrairement au système RC, AFAIK, la désactivation partielle des types de référence n’est pas une option sur le système GC.
Je sais que de nombreux graphismes et jeux publiés utilisent un système basé sur GC, et que la plupart d’entre eux souffrent du manque de déterminisme. Non seulement pour les caractéristiques de performance, mais aussi pour la gestion de la durée de vie des objets. Unity est principalement écrit en C ++, mais la minuscule partie C # cause tous les problèmes de performances étranges. Des applications hybrides HTML et qui souffrent encore de pics imprévisibles sur n’importe quel système. Largement utilisé ne veut pas dire que c'est supérieur. Cela signifie simplement que c'est facile et populaire pour les personnes qui n'ont pas beaucoup d'options.
Mise à jour 2
Encore une fois, pour éviter des discussions ou des discussions inutiles, j’ajoute quelques détails supplémentaires.
@Asik a fourni un avis intéressant sur les pointes de GC. Nous pouvons considérer l’ approche axée sur le type de valeur pour tous les utilisateurs comme un moyen de se soustraire au contenu du GC. Ceci est très attrayant, et même réalisable sur certains systèmes (approche purement fonctionnelle par exemple). Je suis d'accord que c'est bien en théorie. Mais dans la pratique, il y a plusieurs problèmes. Le plus gros problème est que l'application partielle de cette astuce ne fournit pas de véritables caractéristiques sans pointe.
Parce que le problème de latence est toujours un problème tout ou rien . Si vous avez un pic d'image pendant 10 secondes (= 600 images), alors tout le système échoue. Ce n'est pas à propos de savoir comment mieux ou pire. C'est juste réussir ou échouer. (ou moins de 0,0001%) Alors où est la source de pic de GC? C'est une mauvaise distribution de la charge GC. Et c'est parce que le GC est fondamentalement indéterministe. Si vous faites des ordures, cela activera le CPG et le pic atteindra éventuellement. Bien sûr, dans le monde idéal où la charge GC sera toujours idéale, cela ne se produira pas, mais je vis dans le monde réel plutôt que dans un monde idéal imaginaire.
Ensuite, si vous voulez éviter les pointes, vous devez supprimer tous les types de références de l'ensemble du système. Mais c’est difficile, insensé et même impossible en raison de composants inamovibles tels que le système central .NET et la bibliothèque. Utiliser simplement un système non GC est beaucoup plus facile .
Contrairement à GC, la RC est fondamentalement déterministe, et vous n'avez pas à utiliser cette optimisation insensée (purement du type valeur uniquement) pour vous contenter d'éviter le pic. Ce que vous devez faire est de rechercher et d’optimiser la partie qui cause le pic. Dans les systèmes RC, la pointe est un problème d'algorithme local, mais dans les systèmes GC, les pointes sont toujours une question de système global.
Je pense que ma réponse est trop éloignée du sujet et consiste principalement en une répétition des discussions existantes. Si vous voulez vraiment revendiquer une supériorité / infériorité / alternative ou tout autre élément de contenu GC / RC, les discussions sur ce site et StackOverflow sont nombreuses, et vous pouvez continuer à vous battre.