2010-03-14 11 views
16

Ich frage mich, ob die Verwendung langer beschreibender Variablennamen in WinForms C# für die Leistung von Bedeutung ist? Ich stelle diese Frage, da in AutoIt v3 (interpretierte Sprache), dass Variablen mit kurzen Namen wie aa anstelle von veryLongVariableName viel viel schneller ist (wenn Programm ist dann größer als 5-Liner) gebracht wurde. Ich frage mich, ob es in C# genauso ist?Ist die variable Namenslänge für die Performance C# wichtig?

Antwort

21

Nein, tut es nicht. Der Compiler speichert die ursprünglichen Variablennamen nicht, Sie können sich den IL-Code einer kompilierten Assembly mit Disassembler ansehen.

+4

Das ist komisch, denn wenn ich meine Quelle .exe mit Reflektor ansehe, werden Variablennamen angezeigt, die ich benutzt habe. – MadBoy

+0

Wahr, aber wird der Zwischensprachcode in einer .NET-Assembly nicht in die Maschinensprache übersetzt, bevor sie ausgeführt wird? (Siehe auch meine Antwort.) Wenn ja, ist es egal, ob sich Variablennamen noch in der Assembly befinden, denn was Sie dort sehen, ist _nicht_, was ausgeführt wird. – stakx

+2

Compiler erstellt auch PDB-Dateien, die Variablennamen und Code tatsächlich speichern. Aber diese Dateien werden nur zum Debuggen verwendet, nicht zum Ausführen der .NET-Anwendungen. Vielleicht kann Reflector diese Dateien auch lesen. –

1

Nein, ich glaube nicht, dass lange Variablen Auswirkungen auf die Ausführungsleistung einer .NET-Anwendung haben. AFAIK, Zwischencode (in MSIL) in einer .NET-Assembly wird in die Maschinensprache übersetzt, bevor sie ausgeführt wird. Dies würde sein, wo Variablennamen definitiv "rausgeworfen" werden (wenn es nicht schon früher passiert ist) und durch einfache Speicheradressen ersetzt werden.

+0

Wie sieht es mit der Startzeit einer solchen Anwendung aus? Wäre es kürzer? – MadBoy

+0

Variablennamen gelangen nicht zu MSIL. –

+0

Wenn Sie sich Sorgen machen, würde ich sagen, dass Sie versuchen, an der falschen Stelle zu optimieren. Schließlich wird eine Assembly nur einmal geladen (zumindest in normalen Situationen). Selbst wenn das 5 Millisekunden mehr dauert, wird sich dies nicht wirklich auf die gesamte Laufzeitleistung Ihrer Anwendung auswirken. IMHO würde es sich mehr auszahlen, sich um die Leistung innerer Schleifen zu sorgen (die viele Male ausgeführt werden), ineffizienten Datenzugriff (HDD/DB-Zugriff ist viel langsamer als RAM-Speicherzugriff) usw. – stakx

1

Es spielt keine Rolle. Obwohl Sie die Namen beim Dekompilieren erhalten können (siehe andere Beiträge für Details), werden diese Namen nicht von der IL-Anweisung verwendet Lesen von oder Schreiben in Variablen/Felder. Die Variablen und Felder werden durch ein anderes Konstrukt identifiziert. Im Namespace reflection.emit werden diese durch LocalBuilder (für eine lokale Variable oder FieldBuild für Felder) dargestellt und um den Punkt zusätzlich zu betonen: Sie müssen nicht einmal explizit benannt werden.

15

Es ist ein wesentlicher Unterschied zwischen einem Compiler und einem Interpreter. Ein Interpreter führt bei der Interpretation von Code eine Suche nach einem Bezeichnernamen durch. Wenn diese Namenssuche in einer Schleife erfolgt, die viele Male ausgeführt wird, kann die für diese Suche benötigte Zeit von Bedeutung sein. Längere Namen benötigen mehr Zeit.

Der C# -Compiler eliminiert Identifikatornamen in zwei verschiedenen Phasen. Die Namen der lokalen Variablen werden gelöscht und durch Stapelrahmen-Offsets ersetzt, wenn der Quellcode in IL kompiliert wird. Namensraum und Typnamen sind weiterhin in der Assembly vorhanden. Der JIT-Compiler löscht diese und ersetzt sie durch Code-Offsets für Methoden und Datenoffsets für Felder. Die Länge der Bezeichner spielt hier keine Rolle, die Suche erfolgt nur einmal.

Die Kosten der Namenssuche in einem Interpreter zu beseitigen, ist nicht schwer. Ein anständiger Interpreter tokalisiert den Quellcode, im Wesentlichen einen Vorkompilierungsschritt, um den Interpreter effizienter zu machen. Solch ein Interpreter würde auch keine Verlangsamungsproblematik mit langen Identifizierungsnamen haben.

+0

Sollte die angenommene Antwort gewesen sein. – ConfusedDeer

2

Nein, sobald die ursprünglichen Variablennamen kompiliert wurden, werden sie nicht mehr verwendet. Die Größe der Variablennamen sollte sich nur sehr geringfügig auf die Kompilierungszeit auswirken, nicht jedoch auf die Ausführungszeit.

Interpretierte Sprachen sind ein wenig von langen Variablennamen betroffen. Lange Namen sind bei jedem Lauf mehr zu lesen, zu speichern und zu suchen, aber der Affekt sollte sehr klein sein. Die Latenz beim Lesen/Schreiben auf eine Festplatte oder sogar auf den Bildschirm sollte die Verzögerung, die durch längere Variablennamen verursacht wird, weit übersteigen.

Wenn die Ausführungszeit das Problem ist, dann werden effizientere Algorithmen mit höherer Ausführungsrate wahrscheinlich viel größere Renditen liefern als die Verkürzung von Variablennamen. Wenn der Speicherdruck das Problem ist, werden speichereffiziente Algorithmen wahrscheinlich viel mehr sparen als nur die Variablennamen zu verkürzen. Wenn die Lösung algorithmisch so eng wie möglich ist, ist es Zeit für eine neue Sprache.

Es gibt einige absolutes in der Programmierung, aber ich bin zuversichtlich, verkürzte Variablennamen im Quellcode zu sagen, aus Leistungsgründen ist ABSOLUT die falsche Entscheidung jedes Mal.

+0

Dim EscapeYouOftenUseVariableNamesThatAreSoLongThatTheyMayBeConsideredANovellaAllOnTheirOwn;) – ScottS

0

Ich denke, die Frage nach Namen Länge ist nur für Script# Projekte (im Falle der Übersetzung von C# zu JavaScript).

Verwandte Themen