Programmier-Stil : Speicher vs. Quellcode

[maki]

ich mühe mich gerade, mit XSL ein XML-Dokument zusammenzubauen und wenn ich mir da die Template-Aufrufe, Variablen-Deklaration, Verzeigung, Vererbungsmöglichkeiten anschauen,
würde ich am liebsten auch alles durch Java-String-Zusammenbau ersetzen

Ich sag ja nicht das ich das nicht auch schon gemacht habe bzw. nie machen würde *g*
Aber mit JSP+EL ist es mittlerweile nicht schwer zu verhindern dass man HTML in Java zusammenbauen muss.
Apache FOP zB. fand ich auch sehr ätzend.

Vielleicht nächstes Jahr Ich bin nur der Werkstudent, ich werd da meinen Vorgesetzten nicht dumm kommen.

Verständlich.

 

[marasek]

Erklär mal deinem Chef dass das sehr schlechtes Design ist, so etwas (HTML Tags) sollte man nicht im Javacode machen, ist nix anderes als Java Code in JSPs zu verwenden

So pauschal würde ich das nicht unterschreiben. Wenn man sich z. B. wiederverwendbare Widgets schreibt, muss man ja irgendwo HTML erzeugen.

Template-Systeme wie Smarty, mit denen man halbe Betriebssysteme in der Template-Sprache realisieren kann (und das dann auch gemacht wird), finde ich auch nicht so pralle.

 

[maki]

So pauschal würde ich das nicht unterschreiben. Wenn man sich z. B. wiederverwendbare Widgets schreibt, muss man ja irgendwo HTML erzeugen.

Natürlich, zB. mit selbstgeschriebenen JSF/JSP Tags, aber so sieht das hier nicht aus

 

[marasek]

Natürlich, zB. mit selbstgeschriebenen JSF/JSP Tags, aber so sieht das hier nicht aus

Nun ja, von ein paar Zeilen Code will ich noch nicht auf die Qualität des Projekts schliessen. Auch ich hau manchmal ein "<tag>"+wert+"</tag>" raus (in PHP), weils an einer Stelle besser passt.

Allerdings, wenn ich ein leeres Eclipse und die Aufgabe, eine WA zu schreiben bekomme, dann sind die weiter oben erwähnten Methoden garantiert mit das erste, was ich mir programmieren werde.

Ich finde es manchmal ulkig, an welchen Stellen die Leute nicht automatisieren - da schreiben Leute in einem Projekt dutzende von Insert-Queries von Hand, anstatt sich eine Funktion zu schreiben, die eine Tabellennamen und eine HashMap frisst...

 

[Wildcard]

Also ich denke, dass jeder gute Compiler da mitlerweile intern StringBuilder draus baut oder sehe ich das falsch? Getestet hab ich das nicht, aber ich denke SUN ist ja auch nicht ganz dumm

Das ist zwar richtig, es wird in der Regel ein StringBuilder verwendet, aber der Compiler kann nicht korrekt 'scopen'. Daher nimmt man händisch einen StringBuilder wenn es sich um eine Schleife, oder rekursive aufgerufene Methode handelt. Der Performanceunterschied geht dabei schnell in Faktor 1000 und mehr.

 

[Ark]

Was Laufzeitenverhalten angeht, habe ich ein Bild ähnlich dem folgenden im Kopf, das auf deutsche Autobahnen gemünzt ist (bitte um Kommentare):

Ganzzahloperationen/Dereferenzierungen -> Freie Fahrt!
Gleitkommaoperationen -> maximal 130 km/h
Methodenaufrufe -> dichter Verkehr
new -> Baustelle
synchronized -> Grenzübergang mit Grenzkontrolle
Schleifen -> "Ups, verfahren ^^" (Ehrenrunden )

Da dürfte der Code von deinem Chef, hdi, nicht besonders gut wegkommen.

Ark

 

[hdi]

Nochmal um auf meine Frage ganz oben einzugehen:

Wie krieg ich raus wieviel Speicher mein Programm gerade im Moment belegt?

Mittels

[HIGHLIGHT="Java"]System.out.println(Runtime.getRuntime().totalMemory());[/HIGHLIGHT]

bekomm ich in jedem Programm, egal wie komplex oder unkomplex, 5056 kb raus.

Also das kann's ja nicht sein

 

[SlaterB]

leg ein 1.000.000er Array an, dann wirds ne andere Zahl

 

[hdi]

Ja aber korrekt kann das ja nicht sein oder?
Dass eine leere main-Methode 5056 frisst und genauso eine main-Methode
die gerade ein komplexes Objekt erstellt und einige Methoden (GUI, Thread)
angeworfen hat, auch 5056 hat.

 

[SlaterB]

die Aussage ist korrekt soweit man das bei einer derart unscharfen Sache sagen kann,
du interpretierst sie nur falsch, musst noch
Runtime.getRuntime().freeMemory()
abziehen, um den tatsächlich belegten Speicher zu bestimmen

 

[Cody]

@hdi:
Falls Du Eclipse verwendest, schau dir mal DAS PLUGIN an, evtl. bekommst Du ja so eine Antwort auf deine Frage

 

[fjord]

sehr komplex passt in 5056 kb aber nicht rein.

totalMemory() sagt dir nicht wieviele Byte dein Programm belegt, sondern wieviele Byte deinem Programm gerade von der VM zur Verfügung gestellt werden. Wie du auf den Verbrauch kommst hat SlaterB ja schon beschrieben. Der Wert den du in jedem deiner Programme gefunden hast kommt daher, dass die VM dir einfach standardmäßig soviel zur Verfügung stellt. Wenn du mehr brauchst, wird totalMemory() auch mehr anzeigen, bis du bei maxMemory() angekommen bist, dann kommt die nette java.lang.OutOfMemoryError: Java heap space.

 

[Sparkle]

Hi,

Ich stimme den zweien hier zu:

Die "Optimierung" Deines Chefs halte ich für Schwachsinn. Lokale Variablen werden vom Compiler sowieso wegoptimiert.

Stattdessen hätte er mal die ganzen String-Konkatenationen mit dem + Operator wegoptimieren sollen. Das wäre das einzige, was man meiner Meinung nach beanstanden könnte an dem Code.

getSomething().getContent().getNews().getTitle()

Wenn ich sowas sehe, stellen sich meine Fussnaegel hoch... Hat sich dein Chef eigentlich mal ueberlegt, was passiert, wenn eine dieser Methoden null zurueckliefert?

Wieso sollte das schneller sein, als die "Zwischenergebnisse" in lokalen Variablen zu speichern? Immerhin muss das immer wieder aufgerufen werden. Wenn also getSomething() z.B. zuerst mal in einer DB nachsieht... dann passiert das bei jedem dieser Zugriffe. Was so ca. 100000x langsamer sein wird, als die lokale Variable. Selbst wenn da keine DB ist, sind das jeweils vier Methodenaufrufe, die sicherlich auch kein final in ihrer Signatur haben... also kostet auch die Polymorphie noch etwas... nich das das langsam waere, aber sicherlich dauerts laenger, als die lokale Variable...

Oder was passiert in einer multithreaded Umgebung? Was, wenn getSomething() nach 2 Aufrufen etwas anderes zurueckliefert, weil dort eine Aenderung durch eine andere Session durchgefuehrt wurde?

Hirnverbrannt, wenn du mich fragst.

Wenn mir da spontan ein Fall einfallen würde, der "null" liefert, würde ich gleich mal genüsslich vor seinen Augen einen Testlauf damit machen und ihn dann den Fehler suchen lassen. Geht natürlich bei einem Chef nicht. Allgemein ist sowas echt nervig.

Dein Code ist um Meilen besser und ich würde fast Wetten eingehen, dass er nicht einen Deut langsamer ist. Was hier noch vergessen wurde, ist Wartbarkeit und Wiederverwendbarkeit. Letztere ist vielleicht noch gegeben bei passender Kapselung, aber ersteres kann man sich da völlig in die Haare schmieren, wenn kryptische Oschis epidemische Ausmaße annehmen.

Wie gesagt, bei einem Chef kann man sich sowas vielleicht sparen, wenn man nicht auf einer Linie liegt, ansonsten würde ich das auf jeden Fall anbringen, denn auf Dauer ist sowas schwer erträglich. Hilft ja keinem von beiden, wenn der eine Zeit verschwenden muss um zu kapieren, was der andere fabriziert hat.

 

[Vayu]

wenn ich den code deines Chefs sehen würde, würde ich mal eben den Ecipse refactoring mechanismus anschmeissen

lokale variablen!!!!! Soviel power kann ein WebService gar nicht brauchen, dass man dafür auf die Wartbarkeit des Codes verzichtet ...

Schlechter Programmierer dein Chef.

 

[maki]

@hdi

https://visualvm.dev.java.net/

 

[Vayu]

cool das teil kannte ich noch nicht. Danke!

 

[SchonWiederFred]

wobei viele + in einer Zeile nicht proportional zur Anzahl der + Zeichen inperformanter sind

Eigentlich wollte ich Dir ja widersprechen, aber Du hast offenbar Recht.
Hier ein kleines Testprogramm:

String a = "hello";
String b = "beautiful";
String c = "world";
String d = a + b + c;

Und hier der entsprechende Bytecode:

public static void main(java.lang.String[]);
  Code:
   0:	ldc	#16; //String hello
   2:	astore_1
   3:	ldc	#18; //String beautiful
   5:	astore_2
   6:	ldc	#20; //String world
   8:	astore_3
   9:	new	#22; //class java/lang/StringBuilder
   12:	dup
   13:	aload_1
   14:	invokestatic	#24; //Method java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String;
   17:	invokespecial	#30; //Method java/lang/StringBuilder."<init>":(Ljava/lang/String;)V
   20:	aload_2
   21:	invokevirtual	#33; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   24:	aload_3
   25:	invokevirtual	#33; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   28:	invokevirtual	#37; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   31:	astore	4
   33:	return

Es wird tatsächlich nur ein StringBuilder erzeugt. Das war mir neu!

 

[maki]

Wie viele Threads über genau dieses Thema hatten wir eigentlich in den letzen 12 Monaten?
Denke es waren so einige.

Gerüchte sind eben schwer totzukriegen.