Beeinträchtigt MFC die Performance von Programmen?



  • 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.


Anmelden zum Antworten