2017-09-09 6 views
4

Dans Rust, il semble que vous pouvez mettre n'importe quoi dans le main. , Les blocs de caractères, la mise en œuvre des fonctions, variables statiques ...Y at-il un désavantage de performance à tout mettre en main?

Par exemple, cette compile:

fn main() { 
    trait Foo { 
     fn foo(); 
    } 

    impl Foo for f64 { 
     fn foo() {} 
    } 

    struct MyStruct; 

    enum RustIsCool { 
     MyStruct, 
    }; 

    fn bar() { 
     trait Baz { 
      fn baz(); 
     } 

     impl Baz for f64 { 
      fn baz() {} 
     } 
    } 

    static x: f64 = 10.0; 

    println!("This compiles!"); 
} 

Comme vous pouvez le voir, vous pouvez même imbriquer ces choses à l'intérieur d'autres blocs.

Évidemment, cela est mauvais d'un point de vue stylistique; c'est moche, plus difficile à refactoriser, et rend la réutilisation du code plus difficile.

Mais je suis curieux: y a-t-il des frais généraux de performance à faire? Ou le compilateur Rust optimise-t-il les différences?

Répondre

7

Réponse courte: Rien de significatif ne sera différent.

Si vous regardez le LLVM-IR pour your code on playground et le comparez avec code where all of your definitions are outside of main(), vous verrez qu'il n'y a pas de différences (sauf en raison de nommage) dans le mode "Debug". En mode "Release", il n'y a aucune différence.

Cependant, il est certainement possible que l'emplacement de votre code de test puisse affecter la génération de code. Mais ce sont des effets mineurs. Il n'y a rien de fondamental qui aurait besoin d'influencer la génération de code (comme si la définition dans main aurait une référence implicite aux variables de main).

Quelques raisons qui pourraient influer sur la génération de code:

  • Étant donné que les définitions main() ne peuvent pas être utilisés en dehors de main(), cela pourrait être un signal fort à inline fonction appelle à ces choses et supprimer la définition originale, si possible. Ceci, en général, améliorerait les performances.
  • rustc génère un peu différente en théorie pourrait LLVM-IR, donc LLVM générer un code différent (effet papillon)
  • ...