Newsgroup Archiv - Beiträge
auf www.Bastie.de
final zum Beschleunigen
Frager: Richard Körber vom Dienstag, 28. November 2000
Hi!
Ich hoffe, die Frage steht nicht schon in irgendeiner FAQ...
Java soll ja deutlich schneller werden, wenn man so viele Methoden wie
möglich als "final" deklariert.
Stimmt das überhaupt noch seit HotSpot?
Und reicht es auch aus, nur die Klasse selbst "final" zu deklarieren?
Das wäre jedenfalls weniger Schreibaufwand... ;-)
Danke!
Richard Körber
1. Antwort: Andree Große vom: Dienstag, 28. November 2000
Wo steht das denn?
A.G.
1.1 Antwort: Thomas Foerster vom: Dienstag, 28. November 2000
In diversen FAQs/Büchern etc.
Nicht-final Methoden müssen zur Laufzeit dynamisch lokalisiert werden
(von welcher Klasse wird die Methode benötigt?) bevor diese aufgerufen
wird. Das kostet Zeit.
Finale Methoden können nicht überschrieben werden, daher ist diese
Zuordnung zur Laufzeit nicht notwendig. Optimierende Compiler können
final-Methoden auch inline in den aufrufenden Kontext hinein kompilieren,
was den "Aufruf" noch schneller macht. Bei nicht-final Methoden ist das
natürlich nicht möglich.
Eine Klasse final zu deklarieren macht alle alle Methoden ebenso final
(statische Methoden sind in dem Sinne auch final).
MFG
Thomas
1.1.1 Antwort: Matthias Ernst vom: Dienstag, 28. November 2000
> "Nicht-final Methoden müssen zur Laufzeit dynamisch lokalisiert werden
(von welcher Klasse wird die Methode benötigt?) bevor diese aufgerufen wird.
Das kostet Zeit."
Nicht viel. Das wird typischerweise durch vtables, also Sprungtabellen
abgebildet. Weiterhin wird oftmals die statisch ermittelte Methode als default
angenommen, so daß dies bei nicht überschriebenen Methoden einem
Table-Lookup, einem Vergleich und einem direkten Sprung entspricht.
Hotspot geht einen Schritt weiter: Methoden nicht überschriebener
Klassen oder nur einmal implementierter Interfaces werden wie finale
Methoden behandelt und entsprechend direkt angesprungen oder geinlined.
Eine Abhängigkeitsverwaltung sorgt im rechten Moment dafür, daß bei
dynamisch nachgeladenem Code diese Optimierungen rückgängig gemacht
werden.
Literatur dazu:
David L. Detlefs and Ole Agesen.
Inlining of Virtual Methods. In Proceedings of the Thirteenth European
Conference on Object-Oriented Programming, Lisbon, Portugal, June, 1999
http://www.sun.com/research/people/detlefs/bib.html
Debugging Optimized Code with Dynamic Deoptimization
Urs Hölzle, Craig Chambers, and David Ungar
Proceedings of the ACM SIGPLAN '92 Conference on Programming Language
Design and Implementation, pp. 32-43, San Francisco, June, 1992.
http://www.cs.ucsb.edu/oocsb/self/papers/dynamic-deoptimization.html
Matthias
Anmerkung: Bei Verwendung von HotSpot Compilern bringt dies bei weitem nicht mehr
soviel wie bei den Interpretern. Jedoch können hier bei der Client-HotSpot Version
gerade beim Start einer Anwendung, konsequente Verwendung vorausgesetzt, noch
spürbare Gewinne entstehen. Bei Applets, wo meist noch auf Java 1 zurückgegriffen
werden muss und oft nur JIT Compiler zur Verfügung stehen ist der
Geschwingkeitsgewinn noch größer.
zur Übersicht
all rights reserved © Bastie - Sebastian Ritter @:
w³: http://www.Bastie.de
Diese Seite ist Bestandteil der
Internetpräsenz unter http://www.Bastie.de
Java
Cobol
Software
Resourcen
Service
Links
Über mich
Zum Gästebuch
Forum