# Bedeutung von "Overhead"



## Bouyo (1. Jun 2012)

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 (1. Jun 2012)

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 (1. Jun 2012)

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 (1. Jun 2012)

Hier auch nochmal zum nachlesen.


----------



## ARadauer (1. Jun 2012)

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


----------



## Spacerat (1. Jun 2012)

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 (1. Jun 2012)

spacerat hat gesagt.:
			
		

> 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 (1. Jun 2012)

fastjack hat gesagt.:


> wo ist es denn z.B. nicht so?


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


----------



## fastjack (1. Jun 2012)

Wo ist denn ein Overhead bei object re-using?


----------



## Gast2 (1. Jun 2012)

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 (1. Jun 2012)

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


----------



## Spacerat (1. Jun 2012)

fastjack hat gesagt.:


> 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 (1. Jun 2012)

fastjack hat gesagt.:


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



Ja, wohl richtig - aber losgelöst auf:



fastjack hat gesagt.:


> 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 (1. Jun 2012)

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 (1. Jun 2012)

Natürlich verwende ich nur ein Objekt.





Spacerat hat gesagt.:


> 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 (1. Jun 2012)

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

siehe 14:07


----------



## Spacerat (1. Jun 2012)

fastjack hat gesagt.:


> 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 (1. Jun 2012)

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 (1. Jun 2012)

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


----------

