4. Performace-Test: Java vs. C#

Performace-Test: Java vs. C#


  • Cpp_Junky schrieb:

    hustbaer schrieb:

    ...
    Die .NET GUI ist z.B. schonmal deswegen langsam weil an vielen Stellen GDI+ verwendet wird, und GDI+ ist leider nicht hardware-beschleunigt (CPU rendert alles). Das ist IMO ein ganz grosser Punkt.

    Dann kommt noch dazu dass das ganze .NET Framework im allgemeinen, und die System.Windows.Forms.* Dinge im speziellen, eher auf Mächtigkeit, Einfachkeit, Korrektheit, Sicherheit Wert legen als auf Speed, und dementsprechend programmiert sind...

    Hm, und wo sollte man diese niedrigere Performance zu spüren bekommen? Ich hab noch nie erlebt das ein Windows-Form irgendwo hakt weil da zu viel gezeichnet würde oder zu viele Controls in der Maske sind. Wer natürlich mit dem GDI Spiele programmiert ist wohl selber schuld ^^

    Mach ein DataGrid (docked), und lade da 200 Zeilen rein.
    Dann ändere die Fenster-Grösse, so dass sich die Grösse des Grids mit ändert.
    Da kannst du zusehen, wie die Daten von oben nach unten neu aufgebaut werden. Dauert locker ein paar hundert ms. Auf einem 2.13 Ghz Core 2 Duo mit GeForce 6600.
    Dasselbe mit "native" Controls geht so schnell, dass es nichtmal gescheit flimmert, geschweide denn dass man sehen könnte in welcher Richtung er die Grafik aufbaut.

    Wer das nicht langsam nennt, hat wohl gänzlich andere Vorstellungen von schnell und langsam als ich... 🙂

    p.S.: versuch mal ein selbst gezeichnetes Control zu machen, und mach da einfach nur ein FillRect über die ganze Fläche. Ersetze das DataGrin im Beispiel oben durch das selbst gezeichnete Control, und lass das Programm laufen. *schnurch*
    Und wenn du noch Transparenz mit dazunimmst ist alles endgültig aus.

    0
  • G

    @schang: Es ist witzlos, die Performance von zwei Sprachen zu vergleichen, ohne die jeweiligen Implementierungen zu zeigen. Das macht alle Aussagen, die Du in dem Bereich machst, unseriös und unglaubwürdig.

    0
  • ?

    THE_ONE schrieb:

    Was ist denn nun besser (performanter). Und warum??

    Erster Denkfehler besser und performanter ist nicht das Gleiche. Was nutzt Performance wenn es nur bedeutet das das Programm schneller abstürzt?

    THE_ONE schrieb:

    Würde mich gerne etwas weiterbilden.

    weiterbilden ist ein aktiver Vorgang. Wenn Du Dich wirklich weiterbilden willst, MSDN is your friend...

    http://msdn.microsoft.com/de-de/library/2839d5h5(VS.80).aspx

    0
  • T

    [quote="loks"]

    THE_ONE schrieb:

    Erster Denkfehler besser und performanter ist nicht das Gleiche. Was nutzt Performance wenn es nur bedeutet das das Programm schneller abstürzt?

    http://msdn.microsoft.com/de-de/library/2839d5h5(VS.80).aspx

    Erstmal danke für dein Feedback!

    In diesem Fall ist die StringBuilder Variante der String Variante vorzuziehen wenn es um die Performance geht, korrekt?

    Was ist aber unsicherer? Meiner Meinung nach sind beide gleich sicher.
    Bei String wird immer wieder eine neuer String erzeugt.
    Bei StringBuilder wird "Bei Bedarf automatisch Speicherplatz zugeordnet"

    Alles in allem gesehen ist daher die StringBuilder Variante auch besser, korrekt?

    0
  • C

    hustbaer schrieb:

    Mach ein DataGrid (docked), und lade da 200 Zeilen rein.
    Dann ändere die Fenster-Grösse, so dass sich die Grösse des Grids mit ändert.
    Da kannst du zusehen, wie die Daten von oben nach unten neu aufgebaut werden.

    Das liegt wohl eher daran das da sowas wie Autoresize angeschaltet ist und der sich neu zurechtformatiert. Ich will mal behaupten das die olsche Grid-Komponente im VS6 den selben Eiertanz vorführen würde, sofern es solche Autosize Funktionen überhaupt hätte ^^

    p.S.: versuch mal ein selbst gezeichnetes Control zu machen, und mach da einfach nur ein FillRect über die ganze Fläche. Ersetze das DataGrin im Beispiel oben durch das selbst gezeichnete Control, und lass das Programm laufen. *schnurch* ...

    Ich hab ne ganze Palette eigener Controls mit komplett eigenen Darstellungsfunktionen. Da kommt nicht nur FillRect sondern FillRect mit Gradient, Antialias-Text und Bildchen drin und da flimmert nix, geschweige denn das irgendein Performance-Einbruch spürbar wäre. Vielleicht ist deine Vorgehensweise nicht so optimal, oder mein Rechner ist einfach zu schnell 🕶 (P4 @ 3Ghz)

    0
  • K

    @Gregor n wenk spät, nich ? 🤡

    0

  • Cpp_Junky schrieb:

    hustbaer schrieb:

    Mach ein DataGrid (docked), und lade da 200 Zeilen rein.
    Dann ändere die Fenster-Grösse, so dass sich die Grösse des Grids mit ändert.
    Da kannst du zusehen, wie die Daten von oben nach unten neu aufgebaut werden.

    Das liegt wohl eher daran das da sowas wie Autoresize angeschaltet ist und der sich neu zurechtformatiert. Ich will mal behaupten das die olsche Grid-Komponente im VS6 den selben Eiertanz vorführen würde, sofern es solche Autosize Funktionen überhaupt hätte ^^

    Nein, das hat mit Autosize nix zu tun. Autosize ist auch nicht aktiv, das Control ist einfach in ein Panel reingedockt. Das "sizing" der einzelnen Panels/Zellen ist dabei auch nicht das Problem, sondern das "malen" der Zellen sowie das "malen" der Selektierung. Man muss dazu auch garnix resizen, es reicht wenn man "links oben" draufklickt um alle Zeilen zu markieren, und dann in eine Zelle um alle Zeilen wieder zu deselektieren.
    Wenn das Fenster full-screen ist (=1280x1024, ca. 40 Zeilen, je 14 Spalten, also "nichts"), dauert das Selektieren/Deselektieren bei mir je ca. 0,5 Sekunden.
    Als Release compiliert, und NICHT aus dem Studio raus gestartet (beides macht nen wilden Unterschied). Allerdings auf meinem Entwicklungs-PC gestartet -- weiss nicht ob das .NET Framework irgendwie "umkonfiguriert" wird, wenn man Visual Studio installiert.
    Studio ist 2005, OS ist XP Pro SP3.
    Ich kann mal ein Beispiel-Programm machen, wenn du mir nicht glaubst 🙂

    p.S.: versuch mal ein selbst gezeichnetes Control zu machen, und mach da einfach nur ein FillRect über die ganze Fläche. Ersetze das DataGrin im Beispiel oben durch das selbst gezeichnete Control, und lass das Programm laufen. *schnurch* ...

    Ich hab ne ganze Palette eigener Controls mit komplett eigenen Darstellungsfunktionen. Da kommt nicht nur FillRect sondern FillRect mit Gradient, Antialias-Text und Bildchen drin und da flimmert nix, geschweige denn das irgendein Performance-Einbruch spürbar wäre. Vielleicht ist deine Vorgehensweise nicht so optimal, oder mein Rechner ist einfach zu schnell 🕶 (P4 @ 3Ghz)

    Same here. Keine besondere "Vorgehensweise", einfach Zeichen-Code im "OnPaint", nix aufregendes. Und da es wie gesagt Framework Controls auch betrifft, gehe ich mal davon aus dass das "normal" ist.

    p.S.: SQL Server Management Studio (für SQL Server 2005), "OPEN TABLE" -> genauso langsam *schnurch*. Hat also *definitiv* nix mit meinem Code zu tun.

    p.p.S.: hast du vielleicht ein anderes OS als ich (ich wie gesagt XP Pro SP3)? Das wäre vielleicht noch eine Erklärung... Oder verwendest du evtl. ne andere (neuere) Framework/Studio Version (ich 2.0/2005 SP1).

    0
  • K

    Denn es geht mal wieder um Java vs. C#/.NET!

    Endlich mal Abwechslung ... wir haben hier meist nur C++ vs. alle anderen.

    Au ja, toller Test:

    Das Tool parst die C-Platte rekursiv durch, auf der Suche nach 3 vorher spezifizierten Dateien, und vergleicht die MD5-Checksumme, File-Version, und Erstellungsdatum der Dateien mit Referenzdaten.

    Also testest du in Wirklichkeit einfach nur I/O anstatt die "Performance". Vielleicht solltest du vorher festlegen, welche Performance du testet, unter welchen Kriterien, Gesichtspunkten, ....

    0
  • ?

    THE_ONE schrieb:

    Alles in allem gesehen ist daher die StringBuilder Variante auch besser, korrekt?

    Jein. Solche Aussagen kann man nicht pauschalisieren weil es immer auf den Context ankommt. Um zwei Strings zusammenzufügen ist der Stringbuilder die falsche Wahl, um 20 Strings zusammenzufügen dagegen die richtige Wahl.

    Empfohlen dagegen wird in der MSDN String.Format() zu benutzen, was zwar nicht die schnellste Variante ist, aber die Sicherste.

    Also sowas wie: String.Format("{0}{1}", string1, string2);

    0
  • C

    hustbaer schrieb:

    ...
    p.p.S.: hast du vielleicht ein anderes OS als ich (ich wie gesagt XP Pro SP3)? Das wäre vielleicht noch eine Erklärung... Oder verwendest du evtl. ne andere (neuere) Framework/Studio Version (ich 2.0/2005 SP1).

    Jo, ich hab hier ebenfalls WinXP mit SP3, allerdings entwickel ich mit dem VS 2008 und .NET 3.5 Ich werde das mit dem Grid hier mal ausprobieren. Das man da nicht unendlich Daten reinpumpen kann war mir schon klar, aber das der bei 40 Zeilen schon rumeiert 😮 Ich werde hier mal eine special investigation starten 🕶 🕶

    EDIT

    So, hab den Test gerade durchgeführt:
    Gedocktes DataGridView mit DataTable als Datasource. 10.000 Zeilen je 10 Spalten mit Daten. Die einzig spürbare Verzögerung entstand beim Fetching aus der Datenbank (Firebird 2 auf selber Maschine) mit ca 0,5 Sekunden. Jedoch keine Nebeneffekte beim Ändern von Fenster/Spaltengrösse, Maximieren oder was auch immer. Selbst mit Column-Autosize hakt kaum etwas - Erst, wenn ich per Zellengrösse anpassen lasse. Was aber auch verständlich ist, bei 10.000 x 10 Zellen ^^ Version 3.5 scheint da GUI-technisch tatsächlich etwas effizienter zu arbeiten.

    0
Anmelden zum Antworten