Re: wie Array für statische Methoden

Hallo Jochen Theodorou,


> Wie ich schon sagt ist das mit dem Speicher minimal.
> Und zusätzliche Tipparbeit... ähm... du programmierst
> in Java!? Wenn du eine Sprache haben willst in der du
> nicht so viel Tippen willst, dann würde ich dir
> auf gar keinen Fall Java empfehlen ;)

was dann? ;)
Ich bin mir nicht sicher aber ich würde sagen :
logic die ich nicht brauche muss ich keiner Sprache tippen, logic die ich brauche/will muss ich in jeder Sprache tippen (vielleicht
auch mit der Maus zusammenklicken o.ä.)


>> Ich will aber auch keine Kosten verursachen bevor
>> ich nicht weis das diese sich lohnen.
>>
>> [Übereinkommen bezüglich Übersicht]
>>
>> Nun möchte ich aber dem Dispatcher nicht gleich von
>> jeder dieser Klassen eine Instance geben weil ich
>> eben nur Kosten und keine Vorteile sehe. ....
>
> also wenn ich es mir recht überlege, dann würde ich
> die Methoden vielleicht automatisch erzeugen lassen,

colle Idee, aber irgentwo muss ich die Methoden doch tippen, das da ein geeigneter Präprocessor vielleicht 20% Ersparnis bring kann
ich mir zwar gut vorstellen aber mehr glaube ich nicht, dafür sind die 500 Methoden auch wieder nicht ähnlich genug

> vielleicht sogar mitsamt dem Dispatcher

Den Dispatcher gerne, schon wegen der Wartbarkeit und dem automatischen Auffüllen von leeren Cases zur Performanceoptimierung. Bitte
nicht schon wieder über zu frühzeitige Performanceüberlegungen schimpfen, wenn das quasie als Nebenprodukt mit abfällt dann darf ich
doch wohl zugreifen, oder?


> minimaler Aufwand, der mehr Spass macht
> als die Methoden zu schreiben.

schreiben muss ich die aber sowieso egal in welcher Sprache und die Logic in den Methoden wird dadurch auch nicht weniger.


> Und solange du keine Varianten willst und auch keine
> zulassen willst, dann kann die Methode prinzipiell
> auch static sein, aber besonders grosse Vorteile
> wirst du davon nicht haben.

aber wenn, so wie in diesem Fall, die Nachteile noch kleiner sind dann kann ichs doch ruhigen Gewissens machen


> Ich persönlich würde die Methoden villeicht protected
> machen, damit man sie überschrieben kann, zum Beispiel
> um einen Dummy zu benutzen, irgendwelche Ausgaben
> einzufügen oder sonstiges... es gibt da viele Möglichkeiten.

Dafür reicht es IMO den Dispatcher automagisch erzeugen zu lassen und dem Präprocessor die entsprechenden Klassen, mit oder ohne
Debugausgaben, zu nennen.



> Ich denke erst sollte man das Design erstellen, dann
> sollte man überlegen wo vielleicht Flaschehälse auftreten
> werden, aber besser noch ist es erstmal eine
> Testimplementierung zu schreiben und zu überprüfen ob
> dieser Flaschenhals auch tatsächlich einer ist. Und dann,
> wenn erwiesen ist, dass man hier was verbessern kann,
> dann sollte man Änderungen machen. Das bewirkt dass
> die Grundarchitektur im Allgemenein erhalten bleibt,

dann kan es manchmal schon zu spät sein, es kommt auch mal vor das eine Peformanceoptimierung nur mit einer anderen Grundarchitektur
machbar ist (die vielleicht wegen irgendwelcher Kleinigkeiten abgeleht wurde), deshalb bin ich dafür Performanceüberlegungen,
zumindest im kleinen Umfang, immer mit in den Entwurf der Grundarchitektur einzubeziehen.

> diese ist auch in den seltensten Fälle
> ein Problem für die Performance.

also ich hab solche Fälle schon des öfteren gesehen, auch schon mal von mir selbst


> Ausserdem wird der Cod durch die Optimierungen meistens
> komplizierter und dadurch schlechter wartbar.

Ich weis ja nicht wo Du solche Erfahrungen gemacht hast, also ich kann das nicht bestätigen.


>>> Wenn du eine static methode aufrufst musst du auch
>>> eine Reference auf dem Stack haben, nämlich die Klasse.
>>> Das statische "this" sozusagen.
>>
>> Das ist richtig aber die JVM könnte das in den Call direkt
>> einbauen so das der nicht immer erst gesucht werden muss
>> und er muss auch nicht der aufgerufenen Methode zur
>> Verfügung stehen also in deren Stackframe (falls die JVM
>> sowas kennt) kopiert werden. Die nächste JVM ist hier
>> vielleicht etwas besser.
>
> Warum glaubst du sollte das nicht für jede
> beliebge andere Referenz nicht auch gelten?

vtable, die erfordert _mindestens_ einen zusätzlichen Speicherzugriff! Oder was glaubst Du warum die virtuellen Methoden in C++
langsamer als statische sind? Bestimmt nicht weil die Compilerentwickler das nicht besser hinbekommen.
Ich hab mal mit virtuellen Methoden auf einem Microkontroller experimentiert und bin zu dem Schluss gekommen: "Wenn ich virtuelle
Methoden möchte dann muss ich damit leben das diese langsamer sind, selbst wenn ich das ganze in Assembler mache." Ich hab mich dann
trotzdem für die virtuellen Methoden entschieden weil die Vorteile einfach zu groß waren, mein eigener Assemblerversuch war übrigens
kein bischen schneller als der Compileroutput und das werte ich als Qualitätsmerkmal des Compilers.

> Der einzige der da was machen könnte wäre der JIT

ACK

> und der kann entsprechendes auch für "this" machen,
> bzw. für jedes andere Objekt.

aber nicht ganz so weit, die vtable kann er nicht wegzaubern


> ref braucht Platz auf dem Heap, ja, aber wenn du jeder
> Methode OPCode übergeben willst, dann brauchst du Platz
> auf dem Stack... das ist besser?

Der Stack ist sowieso da, die JVM wird ihn wohl kaum kleiner machen wenn ich ihn nicht nutze. Außerdem muss eine Variable auf dem
Stack nicht alociert werden.


> Die Perfomrance bei Methodenaufrufen
> in Java ist wirklich gut.

bei virtuellen Methoden ja, sonst IMO eher nein


> Weil?

Weil Du selber gemessen hast das die statische Methode kaum schneller, oger gar langsamer, ist als die virtuelle Methode. Das ist in
allen compelierenden Sprachen die ich kenne anders.


>> Auf so geringe Kosten werden virtuelle Methoden
>> nie kommen, geht prinzipbedingt nicht.
>
> doch klar,

nein, denk an die vtables

> Es ist ja gerade der Vorteil bei Java einen Compiler
> in der VM zu haben, der zur Laufzeit in der Lage ist
> Dinge zu optimieren, die ein normaler Compiler nicht
> optimieren kann, da er keine flexible Flussanalyse
> machen kann.

Die Vorzüge von JIT-Compilern sind mir bewust und ich denke auch das diesem Konzept die Zukunft gehört, aber es steht erst am Anfang
seiner Entwicklung.


>> Ja, und wenn die JVM-Programmierer morgen merken
>> das es noch statische Methoden gibt dann sind
>> diese übermorgen vielleicht doppelt so schnell.
>
> Glaube ich kaum.

Man wird sehen was die Zukunft bringt.

> Die wissen dass es die gibt.

So war das auch nicht gemeint, ich hab das etwas überspitzt formuliert.


> signifikant schneller aber auch nicht, sodass man
> hier auch keinen Vorteil für static ableiten kann.

aber sie können schneller sein, so das mein Programm mit der nächsten JVM-Version vielleicht etwas Performance zulegt


Grüße
Erik


.

Relevant Pages

  • Re: Cpp Considered Harmful
    ... >> programming language, the compiler, the IDE, the libraries, etc. ... source file, the implementation shall locate the declaration, (and ... to name one of the defining source files on the command line that initiates ... The counterpart to this in Java is accomplished using the following: ...
    (comp.lang.cpp)
  • Re: wie Array =?ISO-8859-15?Q?f=FCr_statische_Methoden?=
    ... Wenn du eine Sprache haben willst in der du nicht so viel Tippen willst, dann würde ich dir auf gar keinen Fall Java empfehlen;) ... Das würde die Sache relativ kompakt machen, weil du keine Methodennamen brauchst und das switch gleich mitschreibst. ... Ich hab mal mit virtuellen Methoden auf einem Microkontroller experimentiert und bin zu dem Schluss gekommen: "Wenn ich virtuelle Methoden möchte dann muss ich damit leben das diese langsamer sind, selbst wenn ich das ganze in Assembler mache." ... dann brauchst du Platz auf dem Stack... ...
    (de.comp.lang.java)
  • Re: What is the fastest method of parsing scheme?
    ... These issues can be eliminated by the use of custom memory allocators ... Any other ideas why Scheme would be faster than C++ and Java for heap ... For example, in my compiler, the procedure ) ...
    (comp.lang.scheme)
  • Re: A 21st Century Apple II?
    ... Java 6 -Xms64m 24.00s ... Which is actually 9.6% better than the C++ Intel compiler. ... I'm sure in some cases the GNU compiler produces better results. ...
    (comp.sys.apple2)
  • Re: C to Java Byte Code
    ... > Java) cannot do, and you cannot write a compliant Java engine that can ... "I think you would agree with me that a C compiler that directly ... compliant ANSI C compiler are described in MPC's product description." ... these "minor differences" include this requirement: ...
    (comp.programming)