Bedeutung von "Overhead"

[Bouyo]

Ich bin noch nicht solange bei der Softwareentwicklung dabei und hatte heute ein intersantes Gespräch mit einem Java Experten. Hierbei ging es eigentlich um das Thema "Performance mit Hibernate". Es viel der ungefähre Wortlaut: "Hibernate ist langsam wegen seinem Overhead". Was aber bedeutet der Begriff "Overhead" im Zusammenhang mit Performance?

 

[fastjack]

z.B.: Du möchtest Daten senden. Die Rohdaten sind 80 Bytes groß. Mit dem Framework XYZ werden das aber beim senden auf einmal 2 Kilobytes. Dann ist der Overhead 2000-80 Bytes.

Bei einem ORM wie Hibernate ist der Overhead das Verpacken der SQL-Ergebnisse in Objekte, im Gegensatz zur normalen einfachen SQL-Nutzung. Das kostet Performance, je nachdem wieviel Overhead entsteht..

 

[Volvagia]

Overhead bezeichnet Daten, die zwar dabei sind aber nich zu den "Hauptdaten" gehören. Z. B. kommen bei einen HTTP-Request "Header\n\nDaten" zurück. Der Header kann zwar geringfügig manipuliert werden, wird aber für die Anfrage benötigt und im Endeffekt ist es egal wie viele Daten man anfordert oder wie groß sie sind (ausgenommen der Zahl im Header, der die Größe angibt ^^), er ist immer da und verbraucht Bandbreite, da der Browser in braucht. Oder bei einer Datenbank vermutlich Speicherplatz.

 

[Camill]

Hier auch nochmal zum nachlesen.

 

[ARadauer]

Wobei es bei Hibernate nicht nur um Daten geht. Hibernate macht einfach mehr... einen Overhead an Verhalten...

 

[Spacerat]

Verwaltungsdaten - Gegenteil (bzw. Gegenstück) von Nutzdaten. Mit anderen Worten, die Daten, die benötigt werden, um mit den Nutzdaten, die dadurch verwaltet werden, vernünftig bzw. überhaupt etwas anfangen zu können. Wer aber behauptet, dass ein grosser Anteil Overhead immer gleichbedeutend mit Performanceeinbussen ist, ist gründlich im Irrtum. Nur im Netzwerk oder sonstigen Streams haben Verwaltungsdaten relativ wenig verloren. Bedeutet: Bevor man Daten per Objekt-Serialisierung über Streams leitet, sollte man sich vorher davon überzeugen, dass es wirklich nicht anders geht.

 

[fastjack]

Wer aber behauptet, dass ein grosser Anteil Overhead immer gleichbedeutend mit Performanceeinbussen ist, ist gründlich im Irrtum.

wo ist es denn z.B. nicht so?

 

[Spacerat]

wo ist es denn z.B. nicht so?

Objekt-Reuse. Da bewirkt ein Overhead stets das Gegenteil, falls nicht macht man was falsch.

 

[fastjack]

Wo ist denn ein Overhead bei object re-using?

 

[Gast2]

Oder zum Beispiel Error Correction: 5 Bit Nutzdaten + 3 Bit Error Correction pro Byte ist erstmal ein heftiger Overhead. Wenn du aber das Byte nun nur einmal statt 2, 3 oder 4 mal komplett neu schicken musst hat sich der Overhead gelohnt.

 

[fastjack]

Da fehlt mir jetzt irgendwie der Bezug auf die "Hibernate", das vom TO angeschnitten wurde.

 

[Spacerat]

Wo ist denn ein Overhead bei object re-using?

Okay, vllt. mach' ich ja was falsch...
Aber Overheads bekommt man im Prinzip bei jedem Objekt. Wieviel, das hängt vom jeweiligem Objekt ab. Und Object-Reuse ohne Objekte? Hmm...???:L

[EDIT]Da gibt es auch keinen Bezug zu Hibernate. Hibernate hat der TO aus meiner Sicht nur dazu verwendet um auf das Thema Overhead zu lenken.[/EDIT]

 

[Gast2]

Da fehlt mir jetzt irgendwie der Bezug auf die "Hibernate", das vom TO angeschnitten wurde.

Ja, wohl richtig - aber losgelöst auf:

wo ist es denn z.B. nicht so?

Kann man schon sagen es gibt Fälle wo Overhead zum Beispiel durch Protokolle durchaus Performance erhöhen.

 

[fastjack]

Bei object re-using benutzt du das doch dasselbe Objekt weiter und erzeugst kein neues, oder? Wo ist da der Overhead?

P.S.: das mit dem Netzwerk finde ich schon sehr speziell.

 

[Spacerat]

Natürlich verwende ich nur ein Objekt.

Aber Overheads bekommt man im Prinzip bei jedem Objekt. Wieviel, das hängt vom jeweiligem Objekt ab.

[EDIT]Wenn man so will, spricht man heutzutage wohl nur noch von Overhead, wenn dieser auch erwähnenswert ist, wie z.B. bei Hibernate. Vllt. spricht man deswegen heutzutage im Bereich Bussysteme auch weniger vom Interbus, weil Overhead dort ein Fremdwort ist? [/EDIT]

 

[fastjack]

Genau, und wenn Du sehr viele Objekte hast verbessert das Deine Performance? So habe ich dich vorhin verstanden...

siehe 14:07

 

[Spacerat]

Genau, und wenn Du sehr viele Objekte hast verbessert das Deine Performance? So habe ich dich vorhin verstanden...

siehe 14:07

Das Verständnis hat sich aber jetzt hoffentlich geändert. Wenn ich weniger Objekte erzeuge steigert das die Performance. Z.B. bevor ich Listenweise Strings im Speicher hin und her bewege, verwende ich doch lieber ein Char-Array. Kurz gesagt, wo auch immer exessiv Immutables "verwurstet" werden fährt man mit Mutables um ein vielfaches besser, selbst wenn solche Objekte sonst den höheren Verwaltungsaufwand haben (z.B. Mutables als Keys in Maps usw.).

 

[knucki]

Nehmt doch zur Beschreibung von Overhead als Beispiel XML.

Viel Struktur umschliesst die eigentlichen Nutzdaten.

Der selbe Informationsgehalt liesse sich zumeist auch in CSV darstellen, aber eben nicht strukturiert.

D.h.
CSV -> reine Nutzdaten(Kopfzeile mal ausgenommen)
XML -> strukturierte Nutzdaten


Zu Objekten allgemein und nicht nur auf Java bezogen:
Wenn ich ein Gitter habe und dort Daten darstelle, welche ich in Datenobjekten jedoch unabhängig vom Gitter verarbeite/ändere, lohnt sich der Overhead eines Feldes am Datenobjekt, dem die Gitterzeile mitgegeben wird. Das Objekt kann sich so selbst um die Anpassung in der Gitterzeile kümmern.

Zum Aktualisieren der Zeile muss dann nicht erst durch das Gitter iteriert werden.

 

[fastjack]

Die Frage ist doch eher, bei wieviel Overhead fängt es an weh zu tun? Das muß man abwägen.