Overhead bei Objektorientierung

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Overhead bei Objektorientierung

Beitrag von m.fuchs »

mse hat geschrieben:
m.fuchs hat geschrieben:[...]Das ist ja der Grund warum man Klassen benutzt.

Mit einem riesigen Overhead. Ja ich weiss, bei den heutigen Computern ist Performance kein Thema mehr. ;-)

Ich habe bisher noch kein Projekt erlebt das Probleme mit dem "riesigen" Overhead der Objektorientierung bekommen hat. Aber schon echt viele die Probleme hatten weil der Quellcode nicht wartbar war.

Vergesst Overhead von Klassen und Objekten. Vergesst Abkürzungen die euch Tipperei ersparen. Das ist in der Wirklichkeit alles nichts im Vergleich zu beschissenen Code.
Wenn wirklich an irgendeiner Stelle die Geschwindigkeit hakt, dann kann man dort optimieren. Bis hin zu Inline-Assembler.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Syntaxerweiterung von Pascal

Beitrag von mse »

Das kann ich so nicht unterschreiben. Wenn man sich bei der Konzipierung über Performance keine Gedanken macht und überall Klassen und dynamischen Speicher verwendet, auch dort wo es keinen Sinn hat, lässt sich das später, wenn die Nachteile sichtbar werden, nicht mehr so leicht korrigieren. Es lässt sich auch "beschissener" objektorientierter Code schreiben...

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Syntaxerweiterung von Pascal

Beitrag von Michl »

m.fuchs hat geschrieben:Vergesst Overhead von Klassen und Objekten. Vergesst Abkürzungen die euch Tipperei ersparen. Das ist in der Wirklichkeit alles nichts im Vergleich zu beschissenen Code.
+ 1 !!!

Man kann echt die Lust verlieren Code zu debuggen, wenn unklare Bezeichner gewählt wurden und dieser sich nicht mehr lesen lässt (ohne, daß man in der Deklaration des Bezeichners nachsehen muss bzw. den Maushint nutzt). Ist mir erst letzte Woche wieder sehr negativ aufgefallen, daß ein Autor pL, pT usw. genutzt hat, anstatt PanelLeft, PanelTop usw. Man kann dann nicht den Code überfliegen und lesen, sondern muss höllisch aufpassen, daß man keine Abkürzung falsch liest. Dabei ist es beim Coden so einfach den (die) Anfangsbuchstaben einzutippen und <Ctrl> + <Space> zu nutzen.
Zuletzt geändert von Michl am Mo 19. Jun 2017, 12:22, insgesamt 1-mal geändert.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Syntaxerweiterung von Pascal

Beitrag von Michl »

mse hat geschrieben:Wenn man sich bei der Konzipierung über Performance keine Gedanken macht und überall Klassen und dynamischen Speicher verwendet, auch dort wo es keinen Sinn hat, lässt sich das später, wenn die Nachteile sichtbar werden, nicht mehr so leicht korrigieren.
Das ist allgemein richtig, bei Beispiel mit dem Button jedoch absolut vernachlässigbar. Ansonsten empfiehlt sich vorher ein Proof of Concept.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Syntaxerweiterung von Pascal

Beitrag von m.fuchs »

mse hat geschrieben:Wenn man sich bei der Konzipierung über Performance keine Gedanken macht

Diese Gedanken sollte man sich durchaus machen.

mse hat geschrieben:und überall Klassen und dynamischen Speicher verwendet, auch dort wo es keinen Sinn hat, lässt sich das später, wenn die Nachteile sichtbar werden, nicht mehr so leicht korrigieren.

Bei was für Projekten sollte dies nicht sinnvoll sein? Abgesehen von 50-Zeilen-Miniprogrammen.

mse hat geschrieben:Es lässt sich auch "beschissener" objektorientierter Code schreiben...

Und zwar jede Menge. Deswegen gibt es so gut Sachen wie Softwarearchitektur, Clean Code und Entwurfsmuster.

Gib mir doch mal ein Beispiel, an welchen Stellen die Objektorientierung bei einem Programm für massive und merkbare Performanceeinbußen geführt hat.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Syntaxerweiterung von Pascal

Beitrag von Timm Thaler »

Michl hat geschrieben:Man kann echt die Lust verlieren Code zu debuggen, wenn unklare Bezeichner gewählt wurden und dieser sich nicht mehr lesen lässt


Und was haben 2-Buchstaben-Variablen aus dem Basic vom KC85 jetzt mit Objektorientierung zu tun? Ich glaub, Du verwechselst hier was.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Syntaxerweiterung von Pascal

Beitrag von mse »

m.fuchs hat geschrieben:Gib mir doch mal ein Beispiel, an welchen Stellen die Objektorientierung bei einem Programm für massive und merkbare Performanceeinbußen geführt hat.

Prominente Beispiele sind Open/Libreoffice, LLVM und FPC.

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Syntaxerweiterung von Pascal

Beitrag von m.fuchs »

mse hat geschrieben:
m.fuchs hat geschrieben:Gib mir doch mal ein Beispiel, an welchen Stellen die Objektorientierung bei einem Programm für massive und merkbare Performanceeinbußen geführt hat.

Prominente Beispiele sind Open/Libreoffice, LLVM und FPC.

Sorry, das ist Unfug. Diese Programme könnte man nicht schneller machen (und dabei auch noch die gleiche Wartbarkeit haben) wenn sie nicht objektorientiert sind. Wie stellst du dir das vor?
Hast du denn einen Beleg dafür, dass die Objektorientierung schuld ist?

Abgesehen davon: was bedeutet denn Performanceeinbußen für dich? Libreoffice läuft bei mir schnell und flüssig. Wo ist das Problem?
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Syntaxerweiterung von Pascal

Beitrag von Timm Thaler »

m.fuchs hat geschrieben:Gib mir doch mal ein Beispiel, an welchen Stellen die Objektorientierung bei einem Programm für massive und merkbare Performanceeinbußen geführt hat.


Du meinst jetzt ausser der Tatsache, dass man heutige Programme auf Rechnern laufen lassen muss, die 4fache Busbreite, 8fache Zahl der Prozessorkerne, 100fache Geschwindigkeit, 1000fachen RAM und 10000fachen Festplattenplatz benötigen wie vor einigen Jahren - und trotzdem die gleichen Funktionen bieten und auch nicht schneller sind?

Zugegeben, kein großes Projekt, aber dafür vergleichbar: Ich hab vor Jahren ein Terminal in Purebasic geschrieben, strukturell programmiert: 56kB Festplatte / 1,7MB RAM. Da es Purebasic für den Raspi nicht gibt, hab ich das auf Qt und C++ portiert, erzwungenermaßen OOP: 3.6MB / 20MB. Da das Programm vom Stick laufen soll, es dabei Ärger mit der Qt-Lib gibt hab ich das nochmal in Lazarus portiert, gemischt OOP (GUI) und strukturell (Uart): 1.8MB / 3.2MB.

Und allein die Zuweisung der Slots in Qt für jedes kleine Kästchen in der GUI ist aufwendiger als das Programm in Lazarus runterzuschreiben, und da hatte ich mit Lazarus gerade neu angefangen.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Overhead bei Objektorientierung

Beitrag von mse »

Ich meine nicht, dass Objektorientierung per se zu langsamen Code führe muss. Ich meine nur, dass es keine gute Idee ist, alles mit TObject oder noch schlimmer mit TComponent Abkömmlingen zu machen. Objektorientierung geht auch mit stack oder statischem Speicher sowie mit eingebetteten Datenbereichen in anderen Objekten. Delphi hätte mit "object" ein entsprechendes Konstrukt, es wurde lediglich vernachlässigt. MSElang wird ihm wieder zu neuem Glanz verhelfen. :-)
Zur Erinnerung, das letzte mal als ich Delphi 7 mit FPC verglichen habe konnte Delphi 7 MSEide in einem Zehntel der Zeit kompilieren und lieferte erst noch besseren Code. Einen Unterschied der Performance von Faktor 10 mit Wartbarkeit zu erklären spricht nicht für die angewandte Methode.
Zuletzt geändert von mse am Mo 19. Jun 2017, 13:32, insgesamt 1-mal geändert.

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Syntaxerweiterung von Pascal

Beitrag von m.fuchs »

Timm Thaler hat geschrieben:Du meinst jetzt ausser der Tatsache, dass man heutige Programme auf Rechnern laufen lassen muss, die 4fache Busbreite, 8fache Zahl der Prozessorkerne, 100fache Geschwindigkeit, 1000fachen RAM und 10000fachen Festplattenplatz benötigen wie vor einigen Jahren - und trotzdem die gleichen Funktionen bieten und auch nicht schneller sind?


Das stimmt doch auch wieder nicht. Natürlich ist der Rechner an dem ich heute sitze deutlich schneller und hat mehr RAM als der an dem ich vor fünf Jahren saß. Im Gegensatz zu vor fünf Jahren lasse ich aber heute drei IDE parallel laufen und habe noch ein Windows in einer Virtualbox offen. Also kriege ich doch mehr Leistung für mehr Hardware. Du kannst ja auch mal vergleichen ob die Software die du heute nutzt exakt soviele Funktionen hat wie vor fünf Jahren. Das man sich übrigens vortrefflich darüber streiten kann, ob diese ganze Funktionalität notwendig ist sollte klar sein. Mehr Funktionen hat aber nichts mit Objektorientierung ja/nein zu tun. Anderes Thema.


Timm Thaler hat geschrieben:Zugegeben, kein großes Projekt, aber dafür vergleichbar: Ich hab vor Jahren ein Terminal in Purebasic geschrieben, strukturell programmiert: 56kB Festplatte / 1,7MB RAM. Da es Purebasic für den Raspi nicht gibt, hab ich das auf Qt und C++ portiert, erzwungenermaßen OOP: 3.6MB / 20MB. Da das Programm vom Stick laufen soll, es dabei Ärger mit der Qt-Lib gibt hab ich das nochmal in Lazarus portiert, gemischt OOP (GUI) und strukturell (Uart): 1.8MB / 3.2MB.
Und allein die Zuweisung der Slots in Qt für jedes kleine Kästchen in der GUI ist aufwendiger als das Programm in Lazarus runterzuschreiben, und da hatte ich mit Lazarus gerade neu angefangen.

Auch das ist ein Äpfel-Birnen-Vergleich. Dass der Aufbau von Qt scheiße ist, heißt ja nicht dass OOP scheiße ist. Und hinzu kommt: Hattest du mit deinem Lazarusprogramm merkbare Performanceeinbußen im Vergleich zu deinem PureBasic-Programm? Da sagst nur dass es 3,2 statt 1,7 MiB RAM verbraucht. Was heißt denn das für dich als Anwender?
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Overhead bei Objektorientierung

Beitrag von m.fuchs »

mse hat geschrieben:Ich meine nicht, dass Objektorientierung per se zu langsamen Code führe muss. Ich meine nur, dass es keine gute Idee ist, alles mit TObject oder noch schlimmer mit TComponent Abkömmlingen zu machen. Objektorientierung geht auch mit stack oder statischem Speicher sowie mit eingebetteten Datenbereichen in anderen Objekten.

Es geht auch mit Records und Pointern auf Prozeduren oder sonstewas. Man kann übrigens auch alles in Assembler schreiben. Die Frage ist nur Warum?

mse hat geschrieben:Delphi hätte mit "object" ein entsprechendes Konstrukt, es wurde lediglich vernachlässigt.

Es kann weniger, Properties fehlen, Interfaces fehlen, ...
Wenn man es im Heap haben will muss man sich selber um Speicherverwaltung und Zeiger kümmern.

mse hat geschrieben:MSElang wird ihm wieder zu neuem Glanz verhelfen. :-)

Ja, ich habe den entsprechenden Thread darüber gelesen. Danach war ich mir sicher, dass ich es mir ersparen kann das Ding auszuprobieren. Sorry, aber ich finde einige deiner Konzepte echt wirr.

mse hat geschrieben:Zur Erinnerung, das letzte mal als ich Delphi 7 mit FPC verglichen habe, konnte Delphi 7 MSEide in einem Zehntel der Zeit kompilieren und lieferte erst noch besseren Code. Einen Unterschied der Performance von Faktor 10 mit Wartbarkeit zu erklären spricht nicht für die angewandte Methode.

Aha, und Delphi ist prozedural geschrieben im Gegensatz zu Freepascal? Oder liegt es vielleicht daran dass FPC was ganz anderes macht als Delphi. Zum Beispiel dass es ein Multiziel-Compiler ist.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Syntaxerweiterung von Pascal

Beitrag von Timm Thaler »

m.fuchs hat geschrieben:Auch das ist ein Äpfel-Birnen-Vergleich.


Ich habe nun nicht allzu viele Projekte, die ich mehrfach auf mehreren Systemen umgesetzt habe. Und ja, bei einem derart einfachen Programm sehe ich keine Performanceeinbußen, ich sehe allenfalls den Speicherbedarf. Ich sehe aber auch, dass ich mit OOP einen Haufen zusätzlichen Aufwand treiben muss, der eigentlich für das Programm überflüssig und allein der OOP geschuldet ist.

Das mag bei großen Projekten anders sein, aber bei kleinen Programmen ist OOP oft ein unnötiger Overhead.

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Syntaxerweiterung von Pascal

Beitrag von m.fuchs »

Timm Thaler hat geschrieben:
m.fuchs hat geschrieben:Auch das ist ein Äpfel-Birnen-Vergleich.

Ich habe nun nicht allzu viele Projekte, die ich mehrfach auf mehreren Systemen umgesetzt habe. Und ja, bei einem derart einfachen Programm sehe ich keine Performanceeinbußen, ich sehe allenfalls den Speicherbedarf.

Ok, das beruhigt mich schonmal.

Timm Thaler hat geschrieben:Ich sehe aber auch, dass ich mit OOP einen Haufen zusätzlichen Aufwand treiben muss, der eigentlich für das Programm überflüssig und allein der OOP geschuldet ist.
Das mag bei großen Projekten anders sein, aber bei kleinen Programmen ist OOP oft ein unnötiger Overhead.

Tja, das ist dann der initiale Aufwand. Der, bei vernünftiger Architektur, dafür später bei Wartung und Erweiterungen sinkt. Wie kann man bei rein prozeduralem Programmieren zum Beispiel vernünftige Unittests machen? Mockups für die Komponenten sind da ja auch schon nicht einfach. Alles Dinge die einem das Leben erleichtern wenn es nicht nur eine Fire-and-Forget-Lösung sein soll.
Und so aufwändig ist das eigentlich auch nicht, ich bezweifele dass ich mit OOP deutlich langsamer bin in der Entwicklung als ohne.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Syntaxerweiterung von Pascal

Beitrag von Timm Thaler »

m.fuchs hat geschrieben:Tja, das ist dann der initiale Aufwand. Der, bei vernünftiger Architektur, dafür später bei Wartung und Erweiterungen sinkt.


Der aber für "kleine" Projekte unnötig hoch ist. Und ja, kleine Projekte sind oft fire und forget, weil das Terminal, wenn es einmal läuft, selten nochmal angefasst wird. Die Anzahl der verfügbaren Schnittstellen von 16 au 32 erhöhen bekommt man auch so gerade noch hin.

Aber zum Beispiel werden im Terminal alle verfügbaren Schnittstellen geprüft und in eine ComboBox eingetragen. Später wird die gewählte Schnittstelle aus der Combobox ausgelesen und nebst anderen gewählten Parametern wie Baudrate usw. zum Öffnen des Uart benutzt. Prozedural sind das ein paar Zeilen. Mit OOP in Qt war das ein übelster Aufriss, die Slots hin und her zu definieren, so dass ich ein paar Funktionen gar nicht implementiert habe, weil ich dann keine Lust mehr hatte und das lieber in FPC gemacht habe. Zumal da schon abzusehen war, dass es mit der Qt Lizenz eh Probleme gibt.

m.fuchs hat geschrieben:Wie kann man bei rein prozeduralem Programmieren zum Beispiel vernünftige Unittests machen?


Doch eher einfacher als bei OOP. Die Prozeduren bekommen einen Eingangswert und liefern einen Rückgabewert oder führen eine Aktion aus. Und Klassen und so Kram kann ich auch in prozeduraler Programmierung verwenden, das ist ja nicht auf OOP beschränkt.

Antworten