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