Beeinträchtigt MFC die Performance von Programmen?
-
Hallo@all,
ich habe ein Programm geschrieben, das alle Datei-Infos aus bestimmten angegebenen Verzeichnissen in von mir definierte File-Objekte einliest und diese dann anschließend auf Gleichheit überprüft. Die Command-Line-Version (ohne MFC) läuft recht schnell. Für alle Verzeichnisse auf meiner Festplatte ( im Moment 13,4 GB belegt) braucht das Programm rund 2 Minuten.
Nun habe ich das ganze mit einer MFC-Oberfläche versehen. Lasse ich das Programm jetzt laufen, dauert das Ganze ewig lange (nach 15 min hab ich abgebrochen). Und zwar alleine das Einlesen und Vergleichen der Datei-Infos, obwohl hier keine MFC-Klassen verwendet werden. Die Funktionalität ist genau die selbe wie in der Command-Line-Version.
Liegt das einzig und allein daran, dass ich überhaupt MFC-Komponenten in mein Programm eingebunden habe? Oder gibt es einen anderen Grund?
Ich hoffe, einer von Euch kann mir weiterhelfen.
Gruß und danke,
Amalthea
-
Hast du vor deinem Test auf Release umgestellt ? Könnte schon mal einer von 1000 Gründen sein...
-
Hatte ich nicht. Habe ich aber jetzt ausprobiert.
Hat leider nichts genützt. Dauert immer noch ewig lange...
-
Das hängt von deinem Programm ab,
wenn das Fenster aber sonst nix tut,
müsste es in der Releaseversion keinen großen Unterschied
geben, falls doch, musst du halt das einlesen
in einem extra Thread laufen lassen.Devil
-
Außer dem Einlesen der Datei-Infos und dem Vergleichen passiert sonst nichts.
Hm, mit Threads hab ich bis jetzt noch gar nichts gemacht. Da müßte ich mich dann erst mal einlesen. Aber wie gesagt, zwischen der Debug- und der Release-Version gibt es keinen Unterschied.
Gruß und danke,
Amalthea
-
Wie und wo startest du es denn im dialog ?
Evtl. bringt es was das einlesen _vor_ dem domodal des Hauptdialogs
in der App zu machen...Devil
-
hm, also mein Hauptdialog muss vorher starten, da der Benutzer angeben soll, welche Verzeichnisse durchsucht werden sollen und welcher Vergleichsmodus angewendet werden soll.
Drückt er dann auf den "Ausführen-Button" werden die Datei-Infos eingelesen und anschließend verglichen. Dann wird ein neuer Dialog erzeugt, die Ergebnisse übergeben (d.h. mit einer set-Funktion gesetzt) und in dem Ergebnis-Dialog dargestellt.
-
Die Ausgabe in einem Dialog dauert. Wenn du 13GB an Datein hast (sagen wir mal 200000 Dateien) dann muss das langsam sein. Das hat aber so nichts mit der MFC zu tun obwohl die sicher etwas langsamer ist als wenn man WINAPI verwendet.
Sollte dein Programm zur Ausgabe nur 1 millisekunde länger dauern als auf der Konsole dann sind das bei 200000 Datein schon 200000 millisekunden.
1 Sekunde = 1000 millisekunden
-
Eventuell bringt es was die Ausgabe und die Berechnung in getrennten Threads laufen zu lassen. Wenn die Berechnung jedesmal warten muss bis die Ausgabe fertig ist dann ist das u.U. nicht so optimal.
-
hm, es sind aber die Einlese- und die Vergleichsfunktion, die so lange brauchen.
Und da wird nichts ausgegeben. Erst anschließend werden die Ergebnisse in einer
Listbox dargestellt. Das geht dann recht schnell. Habs mit dem Debugger
getestet. Es hat nichts mit der Ausgabe zu tun...Gruß Amalthea
-
Dann liegt es aber auch nicht an den MFC. Entweder dein Code ist doch nicht so performant wie du dachtest, oder du testest im Debug-Mode oder deine Compilerflags für den Release-Mode sind verhunzt. Bist du sicher, dass der Code für die Berechnungen im Konsolenprogramm und in der GUI-Version 100%ig identisch ist?
-
ja, bin mir sicher.
Kann es nicht sein, dass durch das Laden der MFC-Klassen Rechenpower
weggenommen wird, die mir dann fehlt um die Datei-Infos in der gleichen Zeit
abzuarbeiten?Gruß, Amalthea
-
Zeig doch mal den Code...
Und nein, die MFC Klassen nehmen keine Rechenpower weg, und
auch den Ram den sie belegen ist wohl zu vernachlässigen.
Wie gibst du denn die Daten aus ?
Und wie holst du sie dir ?
Mit CFileFind oder Windapi ?Devil
-
Wichtig ist, dass ein Anwendung niemals ihre Obflaeche blockiert. Deshalb ist der Einsatz von Threads waermstens zu empfehlen.
Windows schickt fortwaehrend Nachrichten an Fensteranwendungen, deshalb darf ein Message-Handler nicht lange brauchen. Alles was laenger als vielleicht 5-10 ms dauert, sollte man in einem eigenen Thread machen.
Diese Richtlinie gilt fuer alle Betriebssysteme mit grafischer Oberflaeche.
Der Performance-Einbruch kommt daher, dass Windows nicht mit Programmen umgehen kann, die die Oberflaeche blockieren.