Programm viel zu langsam

Hallo,

ich habe in den letzten Wochen einen Camera-Viewer geschrieben, der Bilder von einer IP-Kamera holt (im MJPEG-Format) und diese darstellt.
Nun habe ich gerade wenn das Ausgabebild vergrößtert dargestellt wird, auf meinem Rechner (2x2 GHZ AMD Turion) eine Auslastung von 40-50% (640x480 skaliert auf 800x600, 12 FPS).
Ob ich beim zeichnen eine PictureBox benutze, oder mit GDI+ zeichne ist vollkommen egal, immer die gleiche Last.

Nun hat mein Chef (schreibe meine Bachelor-Thesis da) mir heute ein Tool gezeigt (welches von meinem ersetzt werden soll) was bei selben Konfigurationen nur 5-7% verbraucht.

Wie geht soetwas? Ich habe andere MJPEG-Decoder in C# angeschaut, die sind alle nicht besser als meiner, teilweise sogar schlechter... Wie kommt sowas? Wäre das alles in reinem C++ schneller? Gibt es eine schnellere Art Bilder zu zeichnen? Gibt es (z.B. in den QT-Bibliotheken) Algorithmen die Bilder mit weniger Rechenlast skalieren können?

Ich habe zahllose Artikel zu performanter C#-Programmierung gelesen, habe alle Quellcodes 5 mal überarbeitet um auch keinen Fehler zu machen, aber trotzdem wird es nicht schneller...

Die heute gestetete war eine Debugversion, gibt es einen performanteren Compiler oder Compileroptionen, de das ganze schneller machen?

Weiß nicht mehr weiter...

Danke für eure Hilf im Voraus,

David

Also einen besseren Compiler findest Du nicht, aber das zeichnen per GDI+ ist nicht wirklich schnell.

Ist ja mit ein Grund, warum Vista mit seinem WPF auf DirectX setzt.

Wenn Du deine SW auf DX umsetzt, wird es sicherlich deutlich schneller.
DX hat auch performante Scalierungsfunctionen.

aha, ok! Danke dir, werde ich probieren!

Compileroptions helfen bei schlechten Code nicht sehr viel. Sie können etwas optimieren aber nicht die Implementation(was ist gewollt, was soll es werden) komplett ummodellieren, dazu sind sie nicht intelligent genug, wenn es so wäre bräuchte man auch keine Programmiersprachen mehr. Die Maus zum reinsprechen der Wünsche würde rechen(Startrek).

Leider kann dir niemand weiterhelfen, da du dein Problem nicht konkret darlegst.
Du sprichst von dies und jenem aber nicht von deiner Implementation(etwas Code wäre nett), die die Bilder/Frames offensichtlich mit getpixel holt und in bitzyklen skaliert(5-7%).

Klingt sicher böse, aber sollen wir die Ursache deiner Probleme erraten?
Machs bitte konkreter.

mfg
ikaros

Ok, konkreter:

ich denke es liegt weniger am Code (so schlecht bin ich nun auch nicht) viel mehr an der Art wie ich es mache.

Ich habe es mit GDI+ gemacht, dachte es ist schnell, jedoch wenn die Bilder gleichzeitig noch skaliert werden müssen, ist es zu langsam.
Daher ist hier meine Frage ob es schnellere Wege gibt die Bilder zu zeichnen als GDI+ oder gar unmanaged C/C++ Bibliothekten die das ganze für mich performanter lösen, als die .NET Bibliotheken.

Des weiteren habe ich früher mal eine Art Farbauswahl programmiert (Als ich mit Winform angefangen habe), wo 90 10x5px Panels mit farbe gefüllt waren und man sich eine aussuchen konnte. Wenn ich aus VS kompiliert habe, haben sich die einzelnen Panels langsam aufgebaut (man konnte fast zusehen) Später habe ich dann irgendwas gemacht (veröffentlicht oder so, ich weis es nicht mehr) und es lief alles schnell und man hat den Aufbau der Panels nicht mehr gesehen.
Daher war da meine Frage ob ich evt. grad irgendwie eine langsame "Debugvariante" nutze, mehr nicht!

Und ich bitte dich mich nicht wie irgend einen Idioten zu behandeln. Das keine Compileroption schlechten Code retuschieren kann ist mir klar, aber soll ich hier meine 25 UML-Diagramme und die 1500 Zeilen code pasten?

Wie kommt sowas? Wäre das alles in reinem C++ schneller? Gibt es eine schnellere Art Bilder zu zeichnen? Gibt es (z.B. in den QT-Bibliotheken) Algorithmen die Bilder mit weniger Rechenlast skalieren können?

Hierauf hätte man Dinge antworten können wie "Weil GDI+ für schnelle Bildanwendungen nicht gut ist" oder wie FZelle es auf die Frage "Gibt es eine schnellere Art Bilder zu zeichnen?" getan hat!

Die heute gestetete war eine Debugversion, gibt es einen performanteren Compiler oder Compileroptionen, de das ganze schneller machen?

Auch hier hätten Antworten kommen können wie "Debugcompilate sind normal langsamer als normale" oder sowas...

Ich wollte von euch keine eierlegende Wollmilchsau, nur die Antwort auf die konkret gestellten Fragen 🙂

Original von ikaros
Compileroptions helfen bei schlechten Code nicht sehr viel. Sie können etwas optimieren aber nicht die Implementation(was ist gewollt, was soll es werden) komplett ummodellieren, dazu sind sie nicht intelligent genug, wenn es so wäre bräuchte man auch keine Programmiersprachen mehr. Die Maus zum reinsprechen der Wünsche würde rechen(Startrek).

Wir haben Projekte für die Uni geschrieben, welche z.B. aus 400.000 Wörtern die Annagramme heraussucht haben. Beim GCC gibt es die von mir gemeinten Compileroptionen und diese haben teilweise die Ausführungszeit von 12 Sekunden auf unter 4 Sekunden optimiert (lief auf einerm Sun 4 CPU System).

Zwar waren damit andere Nachteile verbunden, jedoch dachte ich für C# gibt es ähnliches!

*** Edit: war übrigens C++ / STL 🙂

Hallo DavidT,

Und ich bitte dich mich nicht wie irgend einen Idioten zu behandeln.

Habe ich das? Ich dachte eigentlich nicht. Deinen Wissensstand kann übrigems schlecht erraten(Bachelor sagt in diesem Bereich wenig aus, da das Thema einfach mal ein Kürbereich ist).

Das keine Compileroption schlechten Code retuschieren kann ist mir klar, aber soll ich hier meine 25 UML-Diagramme und die 1500 Zeilen code pasten?

Nein ich bat nur nur um Auszüge die vielleicht 2-3x 10 Zeilen ausmachen dürften.

Antworten:
-C++ ist nicht schneller. Auch nicht nativ(Differenzen meist um 2-3%).
-Unterschied besteht in längeren Lade(+Übersetzungs-)zeiten für .Net-Code, dafür ist der übersetzte IL-Code oft schneller in der Ausführung.
-GDI+ ist theoretisch GDI unterlegen, dazu muss man aber die Graka befragen ob sie auch skalieren kann.
-Die GDI+ Möglichkeiten sind für derart simple Möglichkeiten meist ausreichend.

• ja auch unter .Net gibt es Compilerschalter die Ausführung etwas beeinflussen können.
  Ich weiss immer noch nicht genug um weiterzuhelfen.

ikaros

Edit:
Compiler: Unter .Net gibt dergleichen grosse Unterschiede nur beim Exceptionhandling, sonst hält es sich in Grenzen.

Die professionelle Herangehensweise wäre, erstmal genau rauszufinden, wo die meiste Zeit flöten geht. Also Profiler anwerfen.

Mal

myForm.SetStyle(ControlStyles.UserPaint | ControlStyles.AllPaintingInWmPaint |             ControlStyles.DoubleBuffer, true);

im Konstruktor probiert?

Aber ohne Code oder wenigstens eine Beschreibung was du tust, ist es irgendwie schwierig

Der Performanceeinbruch bei Skalierung ist übrigens völlig normal. Ohne Unterstützung durch eine Graka ist das ein hartes Brot für die CPU.

http://msdn2.microsoft.com/en-US/library/1bttkazd(VS.80).aspx

Hallo DavidT!

Ich hatte auch mal ein recht rechenintensives Programm geschrieben. Als ich die Compileroptionen umstellte (von Debug-Modus auf Release), hat sich die Geschwindigkeit um die 25% verbessert. Also in machen Fällen kanns schon hilfreich sein sich da etwas zu spielen. Dass man aber von 50% Auslastung auf 5% kommt - eher nicht. Aber vielleicht ein Schritt in die richtige Richtung.

DirectX ist evt. zu überlegen, da in diesem Fall die Grafikkarte besser einbezogen wird und somit der Prozessor geschont wird.

Mfg Preli