Re: wie Array für statische Methoden

Erik G. schrieb:
[...]
Das mit dem Portforwarding verstehe ich nicht ganz, dadurch bekommt der Host doch keine weitere IP-Adresse sondern ist von außen nur durch eine weitere erreichbar und wenn das Protforwarding in einem NAT-Router erledigt wird merkt der Host ja noch nicht einmal was davon, der NAT-Router ändert ja schließlich die Zieladresse von entsprechend eingehenden Paketen auf eine vom gewünschten Host um.

Wenn du eine IP nach aussen senden musst, dann bist du froh wenn du die IP hast unter der dein Computer erreichbar ist und nciht irgendeine interne IP, die ausserhalb nutzlos ist. Schonmal RMI auf einem NAT-System gemacht?

[...]
Aber welcher Vorteil entsteht wenn sie nicht static sind?

bis jetzt konnte ich noch keinen Erkennen 

na und das ist kein Grund zunächst darauf zu verzichten!?

Für mich klingt das nach einer Fixierung.

Aha, ich will ja hier nicht unhöflich oder undankbar sein aber diese absoluten Ferndiagnosen mag ich nicht. 

Ich Diagnostiziere nicht, ich sage meine Meinung ;)

welcher Nachteil entsteht denn wenn
du die Methoden *nicht* static machst?

Man benötigt für nicht statische Methoden eine Instance von der entsprechenden Klasse und die Kostet auf jeden Fall Speicher selbst wenn es keine lokalen Variablen gibt.

ahem... ich glaube kaum dass das ein besonders starkes Argument ist. Ich hatte ja schon gesgat, dass man nicht optimieren sollte bvor man nicht das eigentliche Problem kennt, oder?

Die Referenz, die der Aufrufer braucht, kostet auch Speicher, klar ist das alles sehr wenig aber die Menge machts, vor allem bei mehreren Aufrufern, 

Glaub mir, so viel ist das nicht.

und wenn man, so wie ich, es gewohnt ist jedes einzelne Byte zu zählen dann kennt man die meisten dieser Verschwender und versucht diese von Anfang an zu vermeiden.

Nunja, ich sagte ja schon dass ich das für falsch halte. Da kommen dann so Tipps wie Object-Pooling z.B. die dann plötzlich den GC der Art verlangsamen, dass man ohne Pool auf jeden Fall besser dran gewesen wäre. Dann wird krampfhaft versucht Singletons zu machen, die dann plötzlich synchronisiert werden müssen und dadurch plötzlich Zeit kosten.

Wenn du eine static methode aufrufst musst du auch eine Reference auf dem Stack haben, nämlich die Klasse. Das statische "this" sozusagen. Du sparst da also nicht wirklich Speicher.

Gerade wenn es mehrere Aufrufer gibt und die immer wieder eine Instace von der Klasse erstellen müssen nur um eine simple Utility-Methode aufzurufen dann belastet das bei Java ja auch noch den GC.

warum müssen die immer wieder eine Instanz erezugen um an die Utility-Methode ranzukommen? Liegt wohl daran dass die aufrufer static sind ;) Zum Beispiel... angenommen Integer hätte die Methode sin, also die Sinus-Funktion, bräuchte ich da für jeden Aufrufer eine Instanz? ja, aber die habe ich auch. Glaub mir, in den meisten Fällen ist das nun wirklich kein Problem... natürlich erst nachdem man seinen Code von diesen Dingen befreit hat.

Beim großen Dispatcher-switch käme noch ein Problem: wenn ich die eigentlichen Arbeitsmethoden, als nicht static, über etwa 30 Klassen verteile (wegen der Übersicht) dann braucht der Dispatcher von allen eine entsprechende Instance und genau da sehe ich eben nur Kosten (Speicher und CPU) und keinen Vorteil also fällt mir die Entscheidung, static oder nicht static, ziemlich leicht.

wieviel kostet denn eine Instanz? Weisst du es? Das Class-Object wird ja auf jeden Fall im Speicher sein müssen. Nicht zu vergessen die Methodenobjekte, die jedes Class-Objekt mit sich herumträgt... Glaub mir, dein Speicher wird durch die 500 Methoden verbraucht, nicht durch 30 Instanzen

Das ist jetzt aber der völlig falsche Weg.
Zu frühzeitige Performanceüberlegungen schaden nur.

Welchen Stellenwert Performanceüberlegungen haben hängt IMHO ganz von der Aufgabenstellung ab so das ich mich hier mit voreiligen Behauptungen eher zurückhalten würde.

Ich habe von *zu frühzeitigen Performanceüberlegungen* gesprochen. Voreilig ist nämlich genau das.

[...]
Bei 'private' kann ich mir verschiedenes vorstellen da für den Methodenaufruf 'this' nicht extra behandelt werden muss aber wenn der Aufruf von einer anderen Klasse kommt dann muss die Referenz auf das Objekt mit 'addp' erst mal irgendwo her geholt werden und das ist ja das Szenario das ich hab.

"private static" ist bei 1000000000 aufrufen bei mir 4% langsamer gewesen als "public". Wie ich schon sagte, das Class-Objekt muss auch irgendwo hergeholt werden. Java macht beim Aufrufen virtueller Methoden eine sehr viel bessere Figur als zum Beispiel C++. Und nur weil virtuals in C++ so langsam waren müssen sie das in Java doch nicht auch sein, oder?

bei anfänglichen Messungen war adds ca. 8% schneller
als addp, dann habe ich die Messung verlängert und
plötzlich ist addp 10% schneller als adds
(bei 10.000.000.000 Druchläufen).

auf Deinem Rechner, mit Deiner JVM, ...
Versteh mich bitte nicht falsch, ich finds gut das Du selber gemessen hast, aber es gibt eben noch mehr Randbedingungen.
Wie erklärst Du Dir eigentlich das Überholen von 'addp'?

vielleicht kann der JIT Compiler diesen Fall besser optimieren. Hätte ich die Server-VM genommen, dann wäre das schon früher passiert.

ein Programm hat normalerweise grössere
Probleme als Performanceverlust bzw. -gewinn
durch  ändern einnes Modifier!

Das weis ich auch, aber es ist auch nur selten so leicht was an der Performace zu ändern wenn man nur einen "geeigneteren" Modifier benutzen braucht.

"geeignet" wird bei mir durch das Objektdesign bestimmt, nicht durch Performance. und selbst das austuaschen eines O(n*n) durch einen O(n) Algorithmus muss nicht unbedingt einen Vorteil bringen, wenn n zu klein ist.

Gruss theo
.

Relevant Pages

  • Re: wie Array =?ISO-8859-15?Q?f=FCr_statische_Methoden?=
    ... Kriterien, über die wir uns wohl einigermaßen einig sind, zutreffen dann benutze ich diesen Modifier eben auch, sonst nicht. ... entsprechenden Klasse und die Kostet auf jeden Fall Speicher selbst wenn es keine lokalen Variablen gibt. ... Gerade wenn es mehrere Aufrufer gibt und die immer wieder eine Instace von der Klasse erstellen müssen nur um eine simple Utility-Methode aufzurufen dann belastet das bei Java ja auch noch den GC. ...
    (de.comp.lang.java)
  • Re: Dictionaries - schnell und effizient?
    ... das ich davon ca. 100.000 Stück kurzzeitig im Speicher halten muss und daher nicht eine eigene Klasse schreiben will. ... Ich nehme mal an, du meinst 100.000 IDs. ... "Hashtable" wahrscheinlich nur geringfügig anders verhalten, Dictionary ist halt einfach die typsichere Variante. ... Eine eigene Klasse wollte ich vermeiden weil das ja Overhead bedeutet, aber ich komme dabei aus dem PHP Bereich wo ein array deutlich ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Richtige Zerstörung von eigenen Objekten
    ... Natürlich sind meine Klasse keine sehr komplexen Klassen. ... das ich direkt keine Speicher freigeben kann. ... Finalize-Methode aufgerufen und durchgefuehrt werden kann. ... >benötigten Klasseninstanzen zu zerstören. ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Memoryblock
    ... Zugriff über folgendes Konstrukt erhalten: ... Speicher zu verschwenden, ... Am meisten lernt man was über die Funktionsweise einer Klasse, ... Wer Komponenten ohne Quelltext oder richtig miese Komponenten ...
    (de.comp.lang.delphi.misc)
  • Re: Disk performance
    ... XP läuft und jetzt unter Ubuntu, musst Du VMware ja zwangsläufig neu installiert haben - und da kann man auch angeben, wieviel Speicher der Host für alle VMs insgesamt nutzen soll. ... M.E. immer nur auf Level einer VM. ...
    (de.comp.os.unix.linux.misc)
Loading