PlusPedia wird derzeit technisch modernisiert. Aktuell laufen Wartungsarbeiten. Für etwaige Unannehmlichkeiten bitten wir um Entschuldigung; es sind aber alle Artikel zugänglich und Sie können PlusPedia genauso nutzen wie immer.

Neue User bitte dringend diese Hinweise lesen:

Anmeldung - E-Mail-Adresse Neue Benutzer benötigen ab sofort eine gültige Email-Adresse. Wenn keine Email ankommt, meldet Euch bitte unter NewU25@PlusPedia.de.

Hinweis zur Passwortsicherheit:
Bitte nutzen Sie Ihr PlusPedia-Passwort nur bei PlusPedia.
Wenn Sie Ihr PlusPedia-Passwort andernorts nutzen, ändern Sie es bitte DORT bis unsere Modernisierung abgeschlossen ist.
Überall wo es sensibel, sollte man generell immer unterschiedliche Passworte verwenden! Das gilt hier und im gesamten Internet.
Aus Gründen der Sicherheit (PlusPedia hatte bis 24.07.2025 kein SSL | https://)

Bei PlusPedia sind Sie sicher: – Wir verarbeiten keine personenbezogenen Daten, erlauben umfassend anonyme Mitarbeit und erfüllen die Datenschutz-Grundverordnung (DSGVO) vollumfänglich. Es haftet der Vorsitzende des Trägervereins.

PlusPedia blüht wieder auf als freundliches deutsches Lexikon.
Wir haben auf die neue Version 1.43.3 aktualisiert.
Wir haben SSL aktiviert.
Hier geht es zu den aktuellen Aktuelle Ereignissen

Overkill (Informatik)

Aus PlusPedia
Version vom 13. November 2025, 15:15 Uhr von Fmrauch (Diskussion | Beiträge) (kann sogar verringern)
Zur Navigation springen Zur Suche springen

Der englische Begriff Overkill bedeutet in der Informatik:

  • eine zu umfangreiche Umsetzung von technisch gesichteten Möglichkeiten im Anwendungsfall, von der das Gesamtkonzept nicht profitiert,
  • eine übermäßige Optimierung, die die Leistung nicht erhöht, sondern verringert.

Ein eindeutiges Beispiel für einen Overkill in der Informatik ist, wenn die gleiche Aufgabe mehrfach bearbeitet wird, obwohl das Ergebnis praktisch schon vorliegt (z.B. durch das Fehlen einer Abbruchbedingung oder Verzweigung[1]).

Der sogenannte Overhead dabei ist die Zeit die in Anspruch genommen wird, bis die Information dort ankommt, wo sie logisch als nächstes benötigt wird („worst case“), abzüglich der durch die Informationstheorie mindestens erwarteten Laufzeit der Information („best case“). Zusätzlicher Overhead entsteht, wenn die Information weniger Nutzdaten enthält.

Bei alten Computern kann man manchmal schneller in den Tastaturpuffer schreiben, als die Zeichen am Bildschirm angezeigt werden. Läuft die Tastatur asynchron, können Zeichen „verschluckt“ werden;[2] oder es erscheint gleich eine ganze Zeile mit dem Buchstaben, den man gerade gedrückt hat.[3]

Software

In Hinsicht auf Software kann ein Produkt mehr Funktionalität enthalten, als der Anwender nutzen kann oder als es sinnvoll für den Einsatzzweck ist. Dabei spielen auch die Peripheriegeräte eine Rolle, doch kann es zur Überforderung auch durch zu viele Optionen und Konfigurationsmöglichkeiten kommen.

So konnte es bei einem Computerspiel wie Tetris zur Situation 'Game Over' kommen, wenn der Spieler es nicht schaffte, die Steine genau genug anzuordnen. Setzte der Spieler einen Stein daneben, entsteht jedesmal Overhead (erkennbar durch Lücken in einer Zeile).

Betriebssysteme können überflüssige Erweiterungen (insbesondere Hintergrunddienste, Daemons) und überladene Funktionen enthalten, die den eigentlichen Arbeitsablauf behindern oder die Gesamt-Performance des Computersystems schwächen. Manche angeblich der Sicherheit dienende Software]] kann durch Suggestion, z.B. dass sie zwangläufig notwendig oder erforderlich ist, einen völlig anderen Zweck erfüllen als angegeben.[4] Bei vernetzten Computern kann sie die Datensicherheit kompromittieren; z.B. durch Ausnutzung eines Pufferüberlaufs[5] oder einer NOP-Rutsche[6] (Mnemonic für NOP: „no operation“).

Bei bestimmten EDV Anlagen fällt die Kommunikation der Softwarekomponenten untereinander und mit der Hardware insgesamt umständlich und langwierig aus, z.B. bei schlecht angebundenen Datenbanken.[7], Browser Erweiterungen).

Softwareentwicklung

In der Softwareentwicklung kann z.B. ein Brute-Force Sortieralgorithmus, der alle möglichen Werte strikt der Reihe nach durchprobiert, bis der positiv-Treffer für eine weitere Iteration gefunden ist, einen gewaltigen Overhead bei der Ausführung produzieren. Der Overhead kann dann, durch eine effizientere Methode (durch weitere logische Ausschließung der nicht gewinnbringenden Fälle wie bei Bubblesort) und erst durch eine rekursive Implementierung (Quicksort) wesentlich reduziert werden. Einfachere Methoden erfordern in der Regel einen hohen Speicherdurchsatz und Verarbeitungsgeschwindigkeit, was in der Regel auch mit einem höheren Energieverbrauch verbunden ist.

Anm.d.A. Ein effizienter Programmierstil führt dazu, die technisch vorgesehen Funktionalität sinnvoll auszunutzen und den Nutzungsgrad falls erforderlich in alle Richtungen optimieren und ggf. portieren zu können (selbst wenn die Ergebnisse nicht direkt zielführend oder zu zeitaufwändig sind).

Um einen Overhead bei der Programmierung zu vermeiden, können Überlegungen zur effizienten Speichernutzung[8] und die Verkürzung von Laufzeiten den Code stark beschleunigen. Insbesondere auf Hardware naher Ebene ist die Codierung bei der Abbildung von Daten auf dem Stack (siehe Stack-orientierte-Maschine, Datentypen) und den unterschiedlichen Speicherbereichen, der Nutzung der Register als schnellste Speicherplätze des Prozessors, ebenso wie eine effiziente Nutzung der Maschinenbefehle (Assembler-Programmierung mit Mnemonics) und Adressierungsarten wichtig. Das zahlt sich bei häufiger Nutzung dieser 'hochoptimierten' Routinen aus, etwa bei der Entwicklung eines Compilers mit Linker-Bibliotheken (die Grundfunktionen für eine breite Front enthalten), oder bei der Generierung zeitkritischer Programmteile.

Die Laufzeiten der Routinen und die Prozessorauslastung hängen dabei u.a. von der verwendeten Prozessorarchitektur (die wiederum eine Implementation der Logik der Maschinenbefehle in Microinstruktionen enthält; und der darin ggf. speziell enthaltenen Optimierungen. Diese Optimierungen sind beispielsweise 3-fach abgestufte Caches oder parallel(-isiert) arbeitenden Einheiten (SMT) oder spezialisierte Befehlssätze, die softwaretechnisch auch richtig genutzt bzw. erstmal unterstützt werden wollen[9][10].

Computerarchitektur

In der Computerarchitektur kann es z.B. ein Overkill sein, wenn eine 1000-MBit-Ethernet Schnittstelle durch die anderen an dem I/O Prozess beteiligten Komponenten (wie Festplatten, CPUs, deren Bussysteme, und die zugehörigen Softwarekomponenten wie Kernel, Treiber, Protokolle, Filesysteme, ...) technisch nicht ausgelastet werden kann. Sollte die Festplatte nur 60 Mbyte/s liefern, kann die Netzwerkverbindung in einer Richtung nur ungefähr zur Hälfte ausgelastet werden. Wenn also auch nur ein Glied in der Kette langsamer ist, entsteht ein Overhead (hier: zeitliches Defizit) bei der Netzwerkkarte. Die Analyse eines solchen „bottlenecks“ lässt sich hier noch durch „Trial and error“ herausfinden.

Hardwarearchitektur

In der Hardwarearchitektur werden z.B. bei einem CPU Cache unterschiedlich schnell reagierende RAM Typen eingesetzt; mit dem Ziel durch Cachingalgorithmen die Ausführung des Codes zu beschleunigen. Die aktiveren Teile sollten dann in den schnelleren Bereichen liegen, sofern sie nicht zu umfangreich sind und herabgestuft werden müssen.[11]

Bei einem RAM-Modul mit ECC oder Parity entsteht Overhead durch die Verwendung dafür notwendiger zusätzlicher Bauteile. Diese Bauteile werden verwendet um die Datenintegrität zu schützen. Besitzt das Modul noch das Chipkill Feature, kann ein ganzer Speicherbereich bei einer Fehlfunktion deaktiviert werden. Diese Features werden besonders bei Rechnern für Dauerbetrieb eingesetzt.

Soll dem Ausfall eines ganzen Systems durch den Ausfall einer kritischen Komponente vorgebeugt werden, bedient man sich der (mehrfach-) redundanten Auslegung der Komponente (z.B. des Netzteils oder der Festplatte).

Eine der hauptsächlich begrenzenden Faktoren bei den gebräuchlichen Architekturen ist die begrenzte Leistung des Hauptprozessors in Verbindung mit dem Hauptspeicher und den Chipsätzen, über die weitere Peripherie (z.B. USB Geräte) angebunden sind.

Die Integration auf Hardwareebene (Hardwarebeschleunigung) und deren Miniaturisierung und die Verschmelzung von Aufgaben wird zunehmend wichtiger[12][13], da die Aufgaben auch immer komplexer und nicht beliebig auf Subsysteme (Kernel an erster Stelle[14]) aufgeteilt werden können.

Eine CPU über die Werte des Herstellers zu übertakten (Overclocking), kann die Lebensdauer herabsetzen[15], falsche Berechnugen liefern, und insbesondere bei zusätzlicher Erhöhung der CPU Kern Spannung den Stromverbrauch überproportional erhöhen. Außerdem kann es zum Ausfallen bestimmter integraler Bestandteile führen (beispielsweise zuerst nur der FPU), die mit Datenverlust oder einem Absturz verbunden sind (wenn Fehler nicht abgefangen werden). Durch die übermäßig entstehende Hitze, die zunehmend zu einer Elektronenmigration führt, kann eine dauerhafte Beschädigung der CPU eintreten. Dabei löst sich Material ab wodurch letztendlich ein Kurzschluss entsteht. Weitere CPU Entwicklungen können bei einer höheren Taktfrequenz die auftretenden Fehler wirksam durch zusätzliche Logik korrigieren[16].


Spezialfälle

Peripheriegeräte

1. Einen TFT-Monitor zu verwenden, dessen native Auflösung über der gelieferten Auflösung der Grafikkarte liegt, ist Overkill. Die zu wenig vorhandenen Informationen werden durch Interpolation ergänzt, wobei ein Qualitätsdefizit in Form von Unschärfe entsteht. Umgekehrt entsteht ein Overhead bei der Grafikkarte, falls die Auflösung des TFT Bildschirms geringer ist als die der Grafik. Dies ist ebenfalls mit einem Qualitätsverlust verbunden, der im Vergleich aber geringer ausfällt, weil der Informationsgehalt vor der (bildgebenden) Rasterung höher war. Röhrenmonitore sind in dieser Hinsicht flexibler, weil Sie einen dynamischen Fokus verwenden, der analog nur durch die Rasterung der Kathodenstrahlröhre Maske begrenzt wird. Eine doppelte Rasterung wie bei der Verwendung eines TFT Bildschirms geschieht nicht.

In manchen Werbeprospekten wird gerne die Bezeichnung 'dpi' falsch, als Einheit für die Auflösung angegeben (1280 x 1024 dpi u.ä.), was im Bezug auf die Erwartungen die man eventuell im Druckbereich haben könnte, ein völlig falsches Leistungsvermögen vermitteln kann.

Da die meisten Drucker das Bild zeilenweise (zur Beschleunigung streifenweise aus Sicht des Druckkopfes) drucken, gibt 'dpi' die Anzahl der maximal vom Druckkopf in einer Linie von 2,54 cm (enstpricht einem Zoll) druckbaren Punkte an. Das wären dann bei einem TFT Bildschirm mit 1280 Pixel Horizontalauflösung 1280 Punkte pro Zoll, in einer Pixelzeile. Schaut man nun weiter, wobei man nicht weiß, dass dpi ein eindimensionaler Begriff ist, würden unfassbare 1,3 Megapixel in einem Quadrat von 2,54 cm Kantenlänge auf dem Bildschirm darstellbar sein; nach Pythagoras im Bezug auf die Paneldiagonale von 19" Zoll aber eben nur 1310720 Pixel oder Punkte auf dem gesamten Bildschirm. Die eigentliche Panelgröße ist dabei oft kleiner als die Angabe in Zoll (durch Rahmen, Verkleidung) für den Monitor.

Außerdem verfügt ein Drucker aber nur über wenige individuelle Farben (z.B. Cyan + Maganta + Yellow + Key Black) oder C+lC+M+lM+Y+K (2 zusätzliche leichte Farben), die durch Rasterung (z.B. nach Floyd-Steinberg Fehlerverteilung) durch Mischung auf dem Papier und optischer Überlagerungseffekte das Druckbild ergeben. Grafikkarten können in der Regel 2^24 (rund 16 Millionen) individuelle Farben im Format: Rot + Grün + Blau + 256 Helligkeits-Abstufungen pro Farbe liefern, viele gängige Flachbildschirme haben aber einen begrenzten Farbraum, der eher nur Tausende Farben darstellen kann. Röhrenmonitore haben diese Einschränkung durch die anaolge Signalverarbeitung nicht.

Bei astronomisch anmutenden Zahlenangaben ist es daher sinnvoll sich vorzustellen, ab diese Angaben extern bei der Ausgabe relevant, oder doch nur interne Übertreibung ist.

Außerdem kann eine Auflösung von 1280x1024 Pixeln (mit einem festen Seitenverhältnis von 5:4 bei einem TFT-Monitor) besonders ungünstig sein, wenn die Digitalkamera ein natives 4:3 Format liefert: Der Bildschirm stellt es entweder im korrekten Seitenverhältnis mit schwarzen Balken („letterbox“) oben und unten dar (dabei geht zusätzliche Bildinformation verloren, da entweder die Grafikkarte oder die Videologik TFT-Monitor die Grafik, zusätzlich zu der Skalierung der Software, noch einmal skaliert) oder zusätzlich vertikal langezogen („stretched“).

2. Eine WLAN Karte mit Verschlüsselung zu verwenden, die wie bei WEP eklatante Sicherheitsmängel mit sich bringt, ist ebenfalls Overkill. Hier ist der Zeitaufwand - sofern ein Sicherheitsrisiko besteht - zum Umgehen der Verschlüsselung dermaßen gering, dass man auch gleich ohne Verschlüsselung arbeiten kann. Eine Verschlüsselung produziert immer Overhead (hier: insbesondere bei Nutzdaten und Sendeleistung), weil die Veränderungen an der Interpretationslogik dem Empfänger auch mitgeteilt werden müssen.

3. Eine vergessene Karte im Rechner (z.B. ISDN Karte im PCI-Slot) verbraucht unnötig Strom, wenn Sie überhaupt nicht für einen Anschluss an das ISDN verwendet wird. Nicht genutzte „onboard“ Komponenten (wie Firewire, WLAN/Ethernet, DSUB-Serial, evtl. auf dem Board vorhandene Sound- und Grafikchips wenn man stattdessen eine Karte verwendet, usw.) kann man (bei x86 PCs) im BIOS abschalten, wodurch zusätzliche Interrupt-Zeit frei wird, was den Computer beschleunigt.

Digitalisierung

Bei der Digitalisierung von Audio-Information entsteht hinsichtlich der analogen Natur der Bias-Einstellung immer ein (wenn auch noch so geringer) Overhead. Dies liegt daran, dass bei falscher Einstellung der Dynamikbereich nicht vollständig ausgenutzt werden kann. Auf digitaler Seite kann das zum Datenverlust mit Clipping, bis zur Zerstörung der Lautsprecher durch Verzerrungen auf analoger Seite führen.

Ob ein Overkill bei dem Codec (z.B. bei Abtastrate und Bittiefe) oder der Wandlung (z.B. selektierte Bauteile) vorliegt, ist letztendlich subjektiv oder Teil der Produktphilosophie.

Verarbeitung digitaler Daten

Bei der Weiterverarbeitung von digitalen Tönen, Bildern oder Videos kann man zusätzlichen Overhead hinsichtlich Qualität vermeiden. Da bei einer wiederholt verlustbehafteten Kompression die Fehlerrate steigt, empfiehlt sich als Ausgangsmaterial das Originalformat zu verwenden.

Im Bereich des Videoschnitts werden (sogar in der Praxis von Fernsehstudios) immer wieder schwache Codecs eingesetzt, obwohl durch eine einfache Auswahl eines besseren Codecs die Qualität nachhaltig verbessert werden könnte. Insbesondere durch (nicht adaptive) Rekodierung in anderen Fernsehstudios, beim Kabel- oder Satellitennetzbetreiber, bis hin zum Internet, wird wertvolle Bandbreite und mögliche Qualität verschenkt.

Betrachtet man die Konvertierung vom NTSC in das PAL Format, sind dabei 10 von 60 Bildern auf Seite von NTSC ein Overhead, weil PAL nur mit 50 Bildern pro Sekunde (fps) arbeitet. Auf der anderen Seite entsteht bei PAL zusätzlicher Overhead, weil besonders die Anzahl der vertikalen Zeilen bei NTSC geringer ist als bei PAL.


Bei der Generierung von Vorschaubildern („thumbnails“), sogar auf Grundlage des JPEG Formats, kann durch spezielle Methoden nur soviel Information aus der Bilddatei gezogen werden, wie beispielsweise für eine kleinere Darstellung von Thumbnails oder Bildern im Webbrowser erforderlich ist. Leider wird oft die gesamte Bildinformation übertragen und dekodiert, und dann erst auf die eigentliche Größe skaliert.

Einzelnachweise

  1. ↑ computerhope.com: „Endless Loop“
  2. ↑ YouTube: Java Robot Controls Mouse Position (hier: Mauseingabe)
  3. ↑ YouTube: The Magic Piano
  4. ↑ heise Security: Vermeintlicher Patch für Internet Explorer enthielt Trojaner vom 12.11.2010
  5. ↑ heise Security: Die Rückkehr der Pufferüberläufe
  6. ↑ heise Security: Tatort Internet Alarm beim Pizzadienst
  7. ↑ Jelovic, Dejan: Why Java is Slow
  8. ↑ Schell, Dominik: Dynamische Programm-Code-Verwaltung und -Optimierung für eingebettete Systeme
  9. ↑ Intel: [AES-NI] Advanced encryption standard instructions
  10. ↑ IBM developerWorks: [AltiVec] From the stacks: TCP/IP checksum vectorization using AltiVec, Part 1
  11. ↑ Hyunjin Lee, Sangyeun Cho, Bruce R. Childers: Performance of Graceful Degradation for Cache Faults
  12. ↑ heise online: AMD Details der 2011 kommenden Prozessorkerne Bobcat und Bulldozer vom 12.11.2009
  13. ↑ computerbase.de: Sandy Bridge Modelle vom 15.11.2010
  14. ↑ Bowman, Ivan: Conceptual Architecture of the Linux Kernel
  15. ↑ c't > Videos: Risiken des Übertaktens
  16. ↑ Intels Resilient Computing: Schnellere Prozessoren durch mehr Rechenfehler

Weblinks

PDFs

Andere Lexika

  • Dieser Artikel wurde in der Wikipedia gelöscht.


Abgerufen von „https://ddn.pluspedia.org/w/index.php?title=Overkill_(Informatik)&oldid=1021259“