2009-04-21 4 views
5

Ich habe eine seltsamste Sache in den letzten paar Tagen erlebt. Ich habe herausgefunden, dass mein Release Build tatsächlich langsamer als die Debug-Version ausführt..Net Release Build arbeitet langsamer als Debug

1. Das Problem

ich endlich alle Sachen von meinem Einstiegspunkt gestrippt (Haupt) in meinem Windows Forms-exe, so dass diese nur:

[STAThread] 
static void Main(params string[] args) 
{ 
    Stopwatch sw = Stopwatch.StartNew(); 
    System.Xml.Serialization.XmlSerializer xmlS = 
     new System.Xml.Serialization.XmlSerializer(typeof(TestClass)); 
    sw.Stop(); 
    MessageBox.Show(sw.Elapsed.ToString()); 
} 

So bin ich eigentlich nicht instanziieren Formulare mehr, nur testen. TestClass ist eine kleine Klasse mit nur drei öffentlichen int Eigenschaften und sonst nichts. Meine Hauptdatei .exe (Windows Forms) ist ~ 1 MB groß, wenn das einen Unterschied macht.

2. Ergebnisse

im Debug-Modus, meine verstrichene Zeit ~ 200 ms, während in Release es ~ 1,2 s dauert.

3. Zusätzliche Informationen

Das Merkwürdige ist, wenn ich versuche, in dieser Lösung als Startup-Projekt ein anderes Projekt zu setzen, denn in diesem Fall ist es (wie oben genau den gleichen Code) schnell funktioniert.

4. Schnell Hack

diese Fehler zu beheben, so schnell wie möglich, habe ich ein neues Exe-Startup-Projekt in meiner Lösung, die das Hauptantragsformular instanziiert und läuft durch mein ersten Eintrag Projekt verweist. In diesem Fall funktioniert es wieder schnell, meine Eingabe-Exe ist jetzt nur 24kb groß und enthält nur eine statische Main-Methode.

Hat jemand schon einmal auf ein ähnliches Verhalten gestoßen? Wenn ich irgendwo anders gestolpert wäre, wenn ich mir den obigen Code anschaue, würde ich wahrscheinlich annehmen, dass irgendwo ein statischer Initialisierer ist, der eine Menge Arbeit in einem separaten Thread erledigt (aber das ist hier nicht der Fall, das habe ich nicht stuff) und weiterhin nur in Release Build laufen?

[Bearbeiten] Weitere Informationen: Ich bin mir bewusst, dass XmlSerializer IL-Code in Runtime generiert, aber meine eigentliche Frage ist, warum es in diesem Fall langsamer als in anderen Fällen funktioniert. Wenn ich nur die tatsächliche Serialisierung benchmarkiere, ist es in Release 3x langsamer (aber nur, wenn ich es von meinem ursprünglichen Projekt aus starte).

[Update] Jetzt für den seltsamsten Teil überhaupt: Nach ein paar Modify/Rebuild-Schritten, mein neues Projekt begann sich als das erste zu verhalten - langsamer Start, langsames Laden. Ich änderte den Projektnamen und die GUID und baute sie neu und es funktioniert wieder schnell.

+0

Bedenken Sie, dass XmlSerializer zur Laufzeit eine Klasse zur Verarbeitung der eigentlichen Serialisierung generiert. Es erzeugt C# -Code und kompiliert es zur Laufzeit. –

+0

Ich verstehe das, aber ich verstehe nicht, warum es immer langsamer in meiner Release-EXE-Anwendung ist.Darüber hinaus kann ich XmlSerializer instanziieren, zum Beispiel für 10 Sekunden schlafen und dann den eigentlichen Serialisierungs-1000-Timer für Benchmarks verwenden - und es ist immer langsamer in Release. – Groo

Antwort

6

Ich denke, möglicherweise ist dies, weil der XmlSerializer NEN-ish beim Start im Release-Modus, aber nicht im Debug-Modus arbeitet. Siehe z.B.

http://blogs.msdn.com/billwert/archive/2008/02/23/use-of-sgen-exe-to-avoid-common-xmlserializer-performance-pitfalls.aspx

für einige Details.

+0

Danke, ich habe tatsächlich SGEN verwendet, um Serialisierungs-Assemblys im Release-Modus zu generieren, aber es war sowieso langsamer. Es ist noch langsamer, wenn ich zuerst einen Serialisierer erstelle und dann nur die Serialisierung selbst benchmarkiere. (übrigens, Ihr Link zeigt dies in Mozilla: "Website auf www.topxml.com wurde als Angriff Website gemeldet") – Groo

+0

Ja, erhalten Sie die gleiche Warnung. Google warnt auch vor dieser Website: http://www.google.de/search?hl=de&q=site%3Awww.topxml.com –

+0

Danke, ich habe die URL auf den ursprünglichen MSDN-Blog korrigiert. – Brian