# Java kleinste Zeiteinheit



## Dude123 (16. Mrz 2010)

Hi,

ich habe einen Algorithmus und würde gerne wissen, wie lange dieser brauch.
Leider komm ich mit System.currentMillis() nicht weit, denn wenn ich den startwert von dem endwert abziehe, dann bekomme ich als ergebnis 0.

also brauch der algorithmus weniger als 1 millisekunden.


Also ist nun meine Frage , ob man es irgendwie schafft auch Zeiten kleiner als 1 Millisekunde zu messen??

Bin für jede Hilfe dankbar 


Gruß


----------



## Der Müde Joe (16. Mrz 2010)

Für den Algorithmus 10000000 oder so Mal aus ;-) (oder für 10000000 Objekte)


----------



## function (16. Mrz 2010)

es gibt noch System.nanoTime()... aber über genauigkeit und reproduzierbarkeit dieser zeit sag ich jetzt mal nichts


----------



## The_S (16. Mrz 2010)

Solche Microbenchmarks sind ohnehin nicht sehr Aussagekräftig.


----------



## SlaterB (16. Mrz 2010)

die Millizeit springt üblicherweise gar nur in 15-16 ms-Schritten


```
public class Test {
    public static void main(String[] args)  {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 20; i++) {
            long t = System.currentTimeMillis();;
            double sum = 0;
            for (int j = 0; j < 2000000; j++) {
                sum = sum * 2;
            }
            System.out.println(" time: " + (System.currentTimeMillis() - t));
        }
        System.out.println("total: " + (System.currentTimeMillis() - start));
   }
}
```


```
time: 16
 time: 0
 time: 0
 time: 16
 time: 0
 time: 0
 time: 0
 time: 15
 time: 0
 time: 0
 time: 0
 time: 16
 time: 0
 time: 0
 time: 0
 time: 0
 time: 0
 time: 0
 time: 15
 time: 0
total: 94
```


----------



## -MacNuke- (16. Mrz 2010)

Der Müde Joe hat gesagt.:


> Für den Algorithmus 10000000 oder so Mal aus ;-) (oder für 10000000 Objekte)



Der einzig sinnvolle Weg.


----------



## Dude123 (16. Mrz 2010)

Hi,

ich bin euch schonmal sehr dankbar ^^

Mir geht es eigentlich nur dadrum dass ich nen bestehenden algorithmus bisschen optimiert habe und nun bisschen vergleichen will.
Das mit den schritten bei den Millisekunden wusse ich noch net, dank dir 

werde wohl wirklich einfach mal den algo paar tausend mal laufen lassen , dort werde ich wohl ein besseres ergebnis bekommen ^^


danke euch allen


----------



## dunhillone (16. Mrz 2010)

Die von java messbare zeit mit System.currentTimeMillis() ist abhängig von der os internen clock.. also wie oft diese die "Anwendungsschleife" durchläuft.


edit: hab noch was gefunden unter time : Java Glossary

55 ms 	Windows 95/98
10 ms 	Windows NT, Windows 2000, Windows XP single processor
15.625 ms 	Windows NT, Windows 2000, Windows XP dual processor
1 or 15.625 ms 	Vista. 1 only if you sleep between calls to currentTimeMillis. I kid you not.
1 ms 	Mac OS X


----------



## Empire Phoenix (16. Mrz 2010)

-MacNuke- hat gesagt.:


> Der einzig sinnvolle Weg.



Ne is auch schwachsinn das paar tausen mal auszuführen, dank hotspot
Was passieren kann: die methode wird als Hotspot erkannt und optimiert.
Nach den ersten x aufrufen wird festgestellt das immer ds selbe nur rauskommen kann, und die methode wird dermaßen optimiert ds sie einfach nur noch eine constante returnt solange sich die parameter net ändern.

Generell kann man realistische benchmarks nur unter realistische bedingungen bekommen.


----------



## bygones (16. Mrz 2010)

OMG...

du hast einen Algorithmus "optimiert" und diese Optimierung laesst sich nicht mal mit millis messen ?

OMG - das muss ja eine bahnbrechende Optimierung gewesen sein...

ala

Tourguide: "Liebe Reisende, ich habe unsere Urlaubsroute optimieren koennen. Wir muessen nun 5x mehr umsteigen, 3x im Kreis laufen, sind aber insgesamt 10sek schneller zu hause"....


----------



## Schumi (16. Mrz 2010)

Vielleicht hat er ja eine for each Schleife durch eine indexbasierte Schleife ersetzt. ;-)


----------



## bygones (16. Mrz 2010)

Schumi hat gesagt.:


> Vielleicht hat er ja eine for each Schleife durch eine indexbasierte Schleife ersetzt. ;-)


rofl


----------



## Ark (16. Mrz 2010)

SlaterB hat gesagt.:


> die Millizeit springt üblicherweise gar nur in 15-16 ms-Schritten


Ich habe zwar die aktuelle Situation nicht so im Blick, aber ich erinnere mich, dass unter Windows es tatsächlich zu diesen Sprüngen im 10-ms-Bereich kam, während auf derselben Maschine unter Linux brav in 1 ms gemessen werden konnte (beide Male [c]System.currentTimeMillis()[/c]).

Ark


----------



## maki (16. Mrz 2010)

Empire Phoenix hat gesagt.:


> Ne is auch schwachsinn das paar tausen mal auszuführen, dank hotspot
> Was passieren kann: die methode wird als Hotspot erkannt und optimiert.
> Nach den ersten x aufrufen wird festgestellt das immer ds selbe nur rauskommen kann, und die methode wird dermaßen optimiert ds sie einfach nur noch eine constante returnt solange sich die parameter net ändern.
> 
> Generell kann man realistische benchmarks nur unter realistische bedingungen bekommen.


-client und es wird kein richtiges dyn. Optimieren betrieben


----------



## SlaterB (16. Mrz 2010)

Ark hat gesagt.:


> [..] dass unter Windows es tatsächlich [..] während auf derselben Maschine unter Linux [..]


eben, üblicherweise


----------



## -MacNuke- (17. Mrz 2010)

Empire Phoenix hat gesagt.:


> Nach den ersten x aufrufen wird festgestellt das immer ds selbe nur rauskommen kann, und die methode wird dermaßen optimiert ds sie einfach nur noch eine constante returnt solange sich die parameter net ändern.
> Generell kann man realistische benchmarks nur unter realistische bedingungen bekommen.



Na wovon wurde denn geredet? Er soll ja nicht 1000 mal das gleiche Objekt übergeben, sondern 1000 unterschiedliche Objekte.


----------



## citizen_erased (17. Mrz 2010)

function hat gesagt.:


> es gibt noch System.nanoTime()... aber über genauigkeit und reproduzierbarkeit dieser zeit sag ich jetzt mal nichts





wahrscheinlich hilft da TimeUnit (Java 2 Platform SE 5.0)


----------



## fastjack (17. Mrz 2010)

Schumi hat gesagt.:
			
		

> Vielleicht hat er ja eine for each Schleife durch eine indexbasierte Schleife ersetzt.



dann hätte er whl. mehr als ein paar Millisekunden gemessen  Aber da performantes programmieren ja hier eh nicht geschätzt wird, braucht man auch eigentlich gar keine Benchmarks mehr.

Getreu nach dem Motto: Gehirn abschalten, der Compiler wirds schon richten, und ansonsten kümmert sich halt HotSpot darum. Programme, die für den Entwickler denken, das wär doch mal eine Revolution oder ?


----------



## maki (17. Mrz 2010)

fastjack hat gesagt.:


> dann hätte er whl. mehr als ein paar Millisekunden gemessen  Aber da performantes programmieren ja hier eh nicht geschätzt wird, braucht man auch eigentlich gar keine Benchmarks mehr.
> 
> Getreu nach dem Motto: Gehirn abschalten, der Compiler wirds schon richten, und ansonsten kümmert sich halt HotSpot darum. Programme, die für den Entwickler denken, das wär doch mal eine Revolution oder ?


Du wirst lachen, aber seit Ende der 70'er Jahre versucht man Programmierern beizubringen, dass Performance nicht das wichtigste ist 

Es reicht, wenn es schnell genug ist, aber Geschwindigkeit alleine reicht bei weitem nicht.
Viel wichtiger ist die Korrektheit &  Wartbarkeit.
Abgesehen davon möchte ich auf die 80/20 Regel hinweisen


----------



## fastjack (17. Mrz 2010)

Da hast Du vollkommen recht, ich meine auch immer wieder nur, daß man ein Auge auf die Performance halten sollte, mehr nicht


----------



## maki (17. Mrz 2010)

fastjack hat gesagt.:


> Da hast Du vollkommen recht, ich meine auch immer wieder nur, daß man ein Auge auf die Performance halten sollte, mehr nicht


Ich sage aber: Ignoriere Performance fast vollkommen, bis sie zum Problem wird, wenn sie ein Problem ist, dann Messe (Profiler) wo sie hängen bleibt und rate nicht 

Klar kann man bestimmte Dinge von Anfang an auf Performace auslegen, dass heisst aber nicht dass es dann auch einen Unterscheid macht (80/20).

Ein Programm mit sauberem Design lässt sich immer verbessern, ein Programm ohne (zB. wenn nur für Performance Entwickelt wurde) lässt sich dagegen kaum noch verbessern.


----------



## Empire Phoenix (17. Mrz 2010)

Bei 1000 verschiedenen Objekten ist die Chance das das erweitern des heaps erstellen des Objektes länger dauert als der Algorithmus... zudem wäre da noch der Gc der da reinfunken kann. Also wird auch nichts.
Btw erfahrungsgemäß gilt 90/10 eher als 80/20, außer die Programme sind sehr kurz.^
30% des codes sind meistens eh nur da um dafür zu sorgen das der user keinen scheiß baut ^^


----------



## Janus (17. Mrz 2010)

In der Realität ist "optimierter" Code allerdings 17x so lang wie die langsame Variante und enthält mindestens doppelt soviele Fehler. Mir ist einfacher, schlanker Kindergartencode, der keinerlei Wert auf Geschwindigkeit, dafür aber auf Les- und Wartbarkeit legt wesentlich lieber.

Sollte sich etwas irgendwann doch mal als Performancebremse erweisen, kann man immer noch optimieren.


----------



## maki (17. Mrz 2010)

> Btw erfahrungsgemäß gilt 90/10 eher als 80/20, außer die Programme sind sehr kurz.


Ja, oft sogar 95/5, aber die Literatur spricht von 80/20


----------



## fastjack (17. Mrz 2010)

Wahrscheinlich meinen wir eh eigentlich alle dasselbe. Ich bekomme nur die Krätze weil es Leute gibt, die sich hinstellen, statt StringBuilder/Buffer zu nutzen, alles mit Strings konkatenieren und dann behaupten Performance kommt später dran. Und an Stellen wo man es bereits erkennt, vernünftige Algorithmen zu nutzen, statt irgendetwas hinzueiern. Das meine ich.


----------



## maki (17. Mrz 2010)

fastjack hat gesagt.:


> Wahrscheinlich meinen wir eh eigentlich alle dasselbe. Ich bekomme nur die Krätze weil es Leute gibt, die sich hinstellen, statt StringBuilder/Buffer zu nutzen, alles mit Strings konkatenieren und dann behaupten Performance kommt später dran. Und an Stellen wo man es bereits erkennt, vernünftige Algorithmen zu nutzen, statt irgendetwas hinzueiern. Das meine ich.


Ich bin einer der Strings mit + konkatiert, ausser in Schleifen.
Warum?
Weil es mindestens (!) genauso schnell ist


----------



## fastjack (17. Mrz 2010)

In Schleifen nicht, weil Du von vornherein weist, das es dann schlechter läuft  Thats it !


----------



## maki (17. Mrz 2010)

fastjack hat gesagt.:


> In Schleifen nicht, weil Du von vornherein weist, das es dann schlechter läuft  Thats it !


Eben 

Der Compiler optimiert schon seit dem JDK 1.3 jedes String +, unter 1.3 zu StringBuffer, später dann zu StringBuilder, d.h. wenn ich versucht habe zu optimieren unter 1.3 mit StringBuffer, läuft mein Programm langsamer als wenn ich mit nur String + verwendet hätte und mit einem aktuellen JDK kompiliere.


----------



## bygones (17. Mrz 2010)

fastjack hat gesagt.:


> Da hast Du vollkommen recht, ich meine auch immer wieder nur, daß man ein Auge auf die Performance halten sollte, mehr nicht



solange das auge zu ist 



Janus hat gesagt.:


> In der Realität ist "optimierter" Code allerdings 17x so lang wie die langsame Variante und enthält mindestens doppelt soviele Fehler. Mir ist einfacher, schlanker Kindergartencode, der keinerlei Wert auf Geschwindigkeit, dafür aber auf Les- und Wartbarkeit legt wesentlich lieber.
> 
> Sollte sich etwas irgendwann doch mal als Performancebremse erweisen, kann man immer noch optimieren.


THIS


----------



## Dude123 (17. Mrz 2010)

dunhillone hat gesagt.:


> Die von java messbare zeit mit System.currentTimeMillis() ist abhängig von der os internen clock.. also wie oft diese die "Anwendungsschleife" durchläuft.
> 
> 
> edit: hab noch was gefunden unter time : Java Glossary
> ...



hey danke fürs raussuchen ^^ sollte dann wohl alles erklären.



> OMG...
> 
> du hast einen Algorithmus "optimiert" und diese Optimierung laesst sich nicht mal mit millis messen ?
> 
> ...



naja komm ich dann auch mal zu dir ^^
du bist wohl der größte affenkopp hier ^^ wirkst aufjedenfall auf mich so.
weißte, du laberst hier i-was von dingen von denen du kein plan hast ^^ getreu nach dem motto : wenn ich keine ahnung habe, laber ich mal dünnschiss ^^
brauchst das hier auch net persönlich nehmen oder so, nur finde ich es schade wie wirklich gute beiträge durch deinen geistigen dünnschiss vollgespammt werden ^^
deine 8000 beiträge sprechen ja auch für dumme spammerei ^^
vielleicht hast du mehr ahnung als ich, vllt fühlst du dich toller, vllt weißt du es auch nicht besser ^^

hauste rein und freu dir nen keks mein juter 



fastjack hat gesagt.:


> dann hätte er whl. mehr als ein paar Millisekunden gemessen  Aber da performantes programmieren ja hier eh nicht geschätzt wird, braucht man auch eigentlich gar keine Benchmarks mehr.
> 
> Getreu nach dem Motto: Gehirn abschalten, der Compiler wirds schon richten, und ansonsten kümmert sich halt HotSpot darum. Programme, die für den Entwickler denken, das wär doch mal eine Revolution oder ?



mhh finde ich wirklich schade, denn warum sollte ich nen total ekelhaften code abliefern, wenn ich doch durch nachdenken ein besseres ergebnis erzielen kann. warum sollte ich da bruteforce mäßig einfach alles ausprobieren , wenn ich doch ein system erkennen kann.
auch wenn es länger dauern sollte das system zu implementieren, dann würde ich doch das lieber machen und evtl falsche lösungen auch über logisches nachdenken ausschließen ^^

also für mich spielt die performance doch schon ne wichtige rolle, es ist jetzt nicht das wichtigste. aber wenn ich doch dann mal nen code habe, dann verbesser ich den doch noch da wo ich kann.
und ich wollte jetzt nur mal gucken inwieweit der code verbesser wurde.

und bis zu 50 fach schneller finde ich doch schon nicht schlecht ^^ dann sollte man das auch machen.

das is meine meinung



maki hat gesagt.:


> Du wirst lachen, aber seit Ende der 70'er Jahre versucht man Programmierern beizubringen, dass Performance nicht das wichtigste ist
> 
> Es reicht, wenn es schnell genug ist, aber Geschwindigkeit alleine reicht bei weitem nicht.
> Viel wichtiger ist die Korrektheit &  Wartbarkeit.
> Abgesehen davon möchte ich auf die 80/20 Regel hinweisen



welche 80/20 regel? ^^
ist bestimmt auch nicht das wichtigste, aber wenn man doch die chance hat da etwas zu machen, warum sollte man nicht ^^



 @ den rest:

danke für die guten antworten 

gruß


----------



## Der Müde Joe (17. Mrz 2010)

>welche 80/20 regel? ^^

80% der Ausfürungszeit laufen in 20% des Codes ab..
80% der User benützen 20% des Programms....
und da gibts noch mehr ;-)

EDIT:
Pareto principle - Wikipedia, the free encyclopedia
und
Program optimization - Wikipedia, the free encyclopedia
(unter Bottlenck)


----------



## fastjack (17. Mrz 2010)

@Dude123 DANKE! Endlich mal jemand dem Performanz auch nicht unwichtig ist. 
Mein Post war nicht gegen Deinen Code gerichtet, den ich sowieso nicht kenne. Sondern hat sich auf die auf die allgemeine Meinung hier zum Thema Performanz bezogen.

P.S.: Allerdings wollen wir hier doch eigentlich alle freundlich bleiben, oder ?


----------



## bygones (17. Mrz 2010)

Dude123 hat gesagt.:


> naja komm ich dann auch mal zu dir ^^
> du bist wohl der größte affenkopp hier ^^ wirkst aufjedenfall auf mich so.
> weißte, du laberst hier i-was von dingen von denen du kein plan hast ^^ getreu nach dem motto : wenn ich keine ahnung habe, laber ich mal dünnschiss ^^
> brauchst das hier auch net persönlich nehmen oder so, nur finde ich es schade wie wirklich gute beiträge durch deinen geistigen dünnschiss vollgespammt werden ^^
> ...


achherrje - da hat aber eine mal ne miese Meinung....

einfach mal ein wenig Luft durch die Hose lassen und weniger ^^, dann erkennst auch du die Wahrheit


----------



## SlaterB (17. Mrz 2010)

dein Text war aber wirklich unpassend, schließlich ließ sich der ganze Algorithmus nicht in Millis messen,
nicht nur die Optimierung

gut möglich, dass sich die Geschwindigkeit von 400 Microsekunden auf 70 Microsekunden erhöhte,
also bisschen was anderes als die 5 sec auf der Weltreise


----------



## Dude123 (17. Mrz 2010)

Der Müde Joe hat gesagt.:


> >welche 80/20 regel? ^^
> 
> 80% der Ausfürungszeit laufen in 20% des Codes ab..
> 80% der User benützen 20% des Programms....
> ...



hehe^^ das gefällt mir mal wieder :lol:



fastjack hat gesagt.:


> @Dude123 DANKE! Endlich mal jemand dem Performanz auch nicht unwichtig ist.
> Mein Post war nicht gegen Deinen Code gerichtet, den ich sowieso nicht kenne. Sondern hat sich auf die auf die allgemeine Meinung hier zum Thema Performanz bezogen.
> 
> P.S.: Allerdings wollen wir hier doch eigentlich alle freundlich bleiben, oder ?



wollte ja auch eigentich freundlich bleiben ^^ so ist das ja nicht 
nur musste halt auch verstehen wie so einige sachen bei mir ankommen ^^ reg mich dann halt darüber auf. 



bygones hat gesagt.:


> achherrje - da hat aber eine mal ne miese Meinung....
> 
> einfach mal ein wenig Luft durch die Hose lassen und weniger ^^, dann erkennst auch du die Wahrheit



welche meinste denn?


----------



## Marco13 (17. Mrz 2010)

*mal einen Link einstreu* AngelikaLanger.com - Java Performance - Micro-Benchmarking - Angelika Langer Training/Consulting


----------



## Dude123 (17. Mrz 2010)

SlaterB hat gesagt.:


> dein Text war aber wirklich unpassend, schließlich ließ sich der ganze Algorithmus nicht in Millis messen,
> nicht nur die Optimierung
> 
> gut möglich, dass sich die Geschwindigkeit von 400 Microsekunden auf 70 Microsekunden erhöhte,
> also bisschen was anderes als die 5 sec auf der Weltreise



jo , war wohl wirklich komisch von mir ausgedrückt, nur habe ich das halt noch nie mit der zeit beachtet ^^

wollte einfach nur wissen ob sich die optimierung auch in der performance widerspiegelt.

ich kann ja auch etwas so optimieren, dass es langsamer wird, dann scheiß ich doch was auf die optimierung.


----------



## SlaterB (17. Mrz 2010)

ich meinte bygones, dessen Kritik setzte falsch an,
war eine Unterstützung für dich   (dich bedeutet hier Dude123, ich beziehe mich immer auf das letzte Posting)


----------



## Dude123 (17. Mrz 2010)

SlaterB hat gesagt.:


> ich meinte bygones, dessen Kritik setzte falsch an,
> war eine Unterstützung für dich   (dich bedeutet hier Dude123, ich beziehe mich immer auf das letzte Posting)



zu faul um zu zitieren? ^^

naja aber dennoch glaube ich dass ich es vllt auch falsch ausgedrückt habe, und eher laienhaft^^

aber danke dass du mich bisschen unterstützt ^^


----------



## bygones (18. Mrz 2010)

SlaterB hat gesagt.:


> dein Text war aber wirklich unpassend, schließlich ließ sich der ganze Algorithmus nicht in Millis messen,
> nicht nur die Optimierung


jetzt mal ernsthaft... (unter der annahme ich habs verstanden)

wir diskutieren hier ueber ein performance optimierung eines Algorithmus, den man selbst schon nicht in millis messen kann ? 

was bringt eine performance optimierung eines algorithmus der so und so schon verdammt schnell ist und nicht messbar ? 

Ich bleib dabei - das ist unsinn und der falsche ansatz.

wie oben geschrieben wurde - performance optimierung sollte nur dann gemacht werden, wenn man nachweisen kann, dass man wirklich ein Performance problem hat. Ich persoenlich kann einfach kein performanceproblem sehen bei einem algorithmus der unter millis rennt.

Meine Kritik bezog sich auch also darauf eine Optimierung zu machen die per se einfach unsinn ist in meinen Augen.


----------



## fastjack (18. Mrz 2010)

> AngelikaLanger.com - Java Performance - Micro-Benchmarking - Angelika Langer Training/Consulting



Aha, wie man sieht beschäftigen sich auch noch andere Leute mit dem Thema Performance und Micro-Benchmarking ... [ironie=on] Angelika Langer stammt wohl auch noch aus den 70érn oder etwa nicht ? [ironie=off]


----------



## Empire Phoenix (18. Mrz 2010)

Da gibte aber gute Beispiele, speziell bei Spielen. (oder String concats, das wird nämlich nicht immer optimiert durch stringbuilder.(wer näheres lesen will guckt in meiner History zu Download von Websites/Performanceproblemen))

Hängt halt davon ab wie oft die Methode aufgerufen wird.(Gutes Beispiel hier sind Boardphase Algorithmen von Jbullet
Man brach nur collisionen berechnen wenn Objekte sich überhaupt berühren können,dies lässt sich einfach optimieren
Bsp: a und b sind 10 meter groß, wenn ich a nicht berühre und es 10 meter wech ist, brauche ich b garnicht testen was 100 meter weit wech ist.

Wobei ich zu den Personen gehöre, die sich als erstes ein Konzept überlegen das alles Möglichst einfach umsetzen kann was benötigt wird, und erst dann anfange zu Programmieren. 
Der Wechsel eines Algorithmuses erweißt sich oft als ein paar hundertmal größer als die optimierung des bereits vorhandenen.


----------



## bygones (18. Mrz 2010)

fastjack hat gesagt.:


> Aha, wie man sieht beschäftigen sich auch noch andere Leute mit dem Thema Performance und Micro-Benchmarking ... [ironie=on] Angelika Langer stammt wohl auch noch aus den 70érn oder etwa nicht ? [ironie=off]



du willst es aber auch nicht verstehen ?

es geht in keiner weise darum dass man sich nicht damit beschaeftigen soll, es geht darum, dass im Namen der Performance meist ein schlechter Code entsteht. Dass performanceoptimierungen angegangen werden, obwohl nicht mal gezeigt wurde dass Performanceprobleme existieren.

Keiner verteufelt das Beschaeftigen mit Performance oder das Wissen wie man Performance testet. 

Das einsetzen von Performanceoptimierung ist aber nun mal in den meisten Faellen a) gar nicht relevant und b) fuehrt zu schlimmeren Ergebnissen.



fastjack hat gesagt.:


> [ironie=on] Angelika Langer stammt wohl auch noch aus den 70érn oder etwa nicht ? [ironie=off]


Uniabschluss 1984... also sogar noch 60er Jahre


----------



## maki (18. Mrz 2010)

fastjack hat gesagt.:


> Aha, wie man sieht beschäftigen sich auch noch andere Leute mit dem Thema Performance und Micro-Benchmarking ... [ironie=on] Angelika Langer stammt wohl auch noch aus den 70érn oder etwa nicht ? [ironie=off]


Es geht doch nur darum, dass Performance nicht (immer) an erster Stelle steht


----------



## fastjack (18. Mrz 2010)

Das man in Stellen die nur einmal durchlaufen werden keinen StringBuilder braucht um zwei Strings zu konkatenieren hat hier auch keiner gesagt. Der Grundtenor meiner Einstellung ist einfach die, das ich mir erst einen performanten Algorithmus überlege, statt einfach drauf los zu programmieren und dann mal hoffe, das HotSpot oder javac für mich alles machen werden. Das sollte eigentlich auch im Interese eines jeden Entwicklers sein. 
Das der überlegte performante Algorithmus schlechter wartbar sein soll, liegt dann wohl eher an schlechter Programmierung. 
Warum sollte ich z.B. in einer bestimmten Schleife unnötige Objekte erzeugen, wenn ich vorher erkennen kann, das z.B. eine Erzeugung reicht, oder es sogar vielleicht, mit vorheriger Überlegung, ganz anders möglich wäre. 

@Dude123
Poste doch mal deinen Algorithmus. Vielleicht kannst Du durch eine höhere Auslastung, indem Du mehrere Objekte verarbeitest, aussagekräftigere Zeiten gewinnen.


----------



## fastjack (18. Mrz 2010)

> Uniabschluss 1984... also sogar noch 60er Jahre



Jep, aber ich bezweifle, das sie da schon mehrere Jahre Erfahrung als eingefleichste Entwicklerin in einem Unternehmen hatte 



> du willst es aber auch nicht verstehen ?



Was ich behaupte ist nur, bekannte nicht-performante Dinge, gar nicht erst zu programmieren. Sprich: Wenn ich bereits vor der Programmierung oder dabei erkennen kann, das es schlecht laufen wird, dann programmiere ich es erst gar nicht so. Kurzum.


----------



## Marco13 (18. Mrz 2010)

Wie gerechtfertigt die Frage nach einer möglichen Optimierung ist, kann man bisher IMHO nicht beantworten. Es ging ja nur darum, dass eine "Verbesserung" gemessen werden sollte. Und diese Verbesserung sollte an etwas gemacht werden, was weniger als 10ms braucht. Man könnte jetzt sagen, dass es keinen Sinn macht, so etwas zu optimieren. Aber wenn man mal absurderweise die Möglichkeit in den Raum stellt, dass der Threadersteller nicht komplett blöd ist, geht es vermutlich NICHT darum, dafür zu sorgen, dass nach einem Buttonklick ein Ergebnis nach 0.2ms statt nach 0.5ms erscheint, sondern darum, dass dieser zu optimierende Teil so oft ausgeführt wird, dass (obwohl er nur 0.5ms braucht) "die meiste Zeit" in diesem Teil verbraten wird, und dadurch z.B. Wartezeiten im Sekundenbereich entstehen, die man minimieren will.

Jetzt könnte man versuchen, EINEN Durchlauf zu messen, und schauen, ob er nach der Optimierung 0.3ms weniger braucht. Aber die Hinweise auf JIT, Microbenchmarks & Co bezogen sich ja darauf, dass das praktisch keinen Sinn macht, und es besser wäre, zu testen, ob durch die Optimierung die tatsächliche Wartezeit z.B. von 5 Sekunden auf 2 Sekunden reduziert wird. Das KANN dann mit einem _geeigneten_ Microbenchmark abgeschätzt werden. Und deswegen auch der Link. 
Und wenn man glaubt, man müsse mit Kritik an Angelika Langer nicht so zurückhaltend sein, dann sollte man sich mal ihre Seite etwas genauer ansehen. Die weiß schon, wovon sie redet. Kritisieren und in Frage stellen kann man das natürlich trotzdem, aber man läuft Gefahr, damit nicht ernst genommen zu werden


----------



## Janus (18. Mrz 2010)

fastjack hat gesagt.:


> Der Grundtenor meiner Einstellung ist einfach die, das ich mir erst einen performanten Algorithmus überlege, statt einfach drauf los zu programmieren und dann mal hoffe, das HotSpot oder javac für mich alles machen werden.



Das bezweifelt auch niemand. Aber du scheinst der Meinung zu sein, dass Details der Implementierung (String Konkatenation statt StringBuilder etc.) bereits zum Algorithmus gehören und das ist schlicht falsch.

Ob ich nun ein Bubblesort oder Quicksort verwende, ist eine grundsätzlich Designentscheidung. Wenn der Quicksort nicht perfekt implementiert ist, bleibt die Komplexität davon trotzdem unberührt und selbst ein optimal implementierter Bubblesort wird die Performance nur verschlechtern können.

Darum reden hier soviele von Mikrooptimierungen und halten sie für nahezu überflüssig - was sie in fast allen Fällen auch sind.


----------



## fastjack (18. Mrz 2010)

> Kritik an Angelika Langer



seh ich nicht ... Lies das mal bitte genauer. Das bezog sich darauf, daß gesagt wurde, seit den 70érn beschäftigen sich Leute damit, anderen Leuten zu sagen sie sollen nicht viel Wert auf Performanz legen. Ich vertrete durchaus die Meinung, man sollte Wert auf Performanz legen. Daher mein Posting, daß es durchaus noch andere Personen gibt, die so denken wie ich


----------



## fastjack (18. Mrz 2010)

@Janus sry, das war ein wenig unglücklich ausgedrückt von mir. Das Beispiel "String Konkatenation statt StringBuilder" wird aber leider nur zu in Schleifen verwendet, ebenso wie überflüssige Objekterzeugungen. Ich denke das kann man beim Entwickeln gleich vermeiden, ohne dabei großartig an Wartungsverhalten einzubüßen, oder etwa nicht ? Und schon hat man indirekt etwas für die Performanz getan.


----------



## maki (18. Mrz 2010)

> Daher mein Posting, daß es durchaus noch andere Personen gibt, die so denken wie ich


Finde ich gewagt die Aussage, wie kommst du denn darauf?


----------



## fastjack (18. Mrz 2010)

Mal eine kurze Frage an alle Performancekritiker: Wie groß war bisher Eure größte Serveranwendung, an der Ihr bis jetzt mitgearbeitet habt? Zwei Tabellen, drei, oder sogar gar keine Datenbank? 10 Datensätze, oder vielleicht sogar 100? Oder vielleicht überhaupt keine?!?! 

Theorie ist toll, labern auch, aber es gibt nun mal Bereiche, die müssen von vornherein schnell sein, einfach weil die Hardware in irgendeinem Keller minderwertig ist oder gar keine Mittel für nen teuren Server zur Verfügung stehen. Und da nutzt es mir relativ wenig, ob javac in der Version XXX jetzt meinen Schietcode aufräumt, bei dem ich zu faul war, den gleich richtig zu programmieren, oder nicht. Und wenn ich mich dann auch noch aus Bequemlichkeit auf die (auto) Optimierung verlasse, na super, wenn die in der nächsten Version nicht mehr funktioniert. Prost!


----------



## maki (18. Mrz 2010)

> Mal eine kurze Frage an alle Performancekritiker: Wie groß war bisher Eure größte Serveranwendung, an der Ihr bis jetzt mitgearbeitet habt? Zwei Tabellen, drei, oder sogar gar keine Datenbank? 10 Datensätze, oder vielleicht sogar 100? Oder vielleicht überhaupt keine?!?!


Insgesamt 2000 User von denen bis zu 200 gleichzeitig mit der Anwendung arbeiteten, um die 120 Tabellen, ca. 800000 Codezeilen, aber das weiss ich nicht mehr so genau.
Scalierbarkeit != Performance
Sonst würden wir alle noch Maschinencode oder höchstens Assembler hacken 

Es geht ja nicht darum Anwendungen so langsam wie möglich machen, sondern darum, dass man nicht als allererstes an Performace denkt, ab einer bestimmten größe (Codebasis) kostet die Wartung des Codes mittelfristig weit mehr als die Serverhardware.

Verstehe auch das Problerm nciht ehrlich gesagt, Profiler gibt es umsonst, damit findet man dann die echten Bottlenecks und kann immer noch was daran ändern, sofern dass Design das zulässt.


----------



## fastjack (18. Mrz 2010)

Mein Gott, ich meine doch keine riesigen Änderungen. Ich meine diese kleinen Sachen wie z.B. häufige Konkatenierungen auf denselben String in größeren Schleifen, die einem ins Auge brennen, weil der gesunde Menschenverstand einem vorher schon sagt das das länger dauern kann ist. Dafür brauche ich keinen Profiler und meine Anwendung läßt sich genauso warten wie vorher. 
Also kleine Sachen, die ich selber vermeiden kann, ohne das sich später jemand mit einem Profiler ne Birne machen muß.


----------



## Dude123 (18. Mrz 2010)

hi,

also eigentlich ging es bei mir garnicht um nen speziellen algorithmus, da hab ich mich wohl falsch ausgedrüct ^^ dachte aber auch net dass es dann nun zu so einem gespräch hier führt.

ob ich nun 2000 versuche brauche um ein ergebnis zu bekommen , statt 150.000, finde ich doch schon wichtig.

kla läuft das auch alles super mit den 150K oder noch mehr, nur warum sollte ich das so machen, wenn ich doch dann am ende bemerke , "hey, da lässt sich ja noch was optimieren"

und was anderes wollte ich eigentlich nicht machen.

wollte dann einfach testen, inwieweit sich die "optimierung" bei dem lösen auch in der gebrauchten zeit wiederspiegelt.

denn was bringt es mir, wenn ich es schaffe nurnoch 1/100 der eigentlich benötigten lösungen zu testen, wenn ich dafür mehr zeit brauche?


performance und ordentlicher code ist für mich schon sehr wichtig und sollte man auch immer drauf achten, denn was bringt es mir wenn ich da total die scheiße hinklatsche und 1000 schleifen hintereinanderpacke, obwohl ich alle zu 5 schleifen zusammenpacken kann.

oder auch das logische ausschließen.

muss etwas immer getestet werden, oder nur in speziellen fällen.

und da finde ich es doch schon hilfreich zu wissen, wie man sowas am besten messen kann und was anderes wollte ich hier auch nicht erfahren 
naja abgesehen von der 80/20 regel ^^ die is cool 

ich bin auch einer der einfach drauf los schreibt und alles erstmal macht. dann setzt ich mich aber hin und hau am ende alle sachen raus. nicht weil ich es muss, sondern weil ich es einfach so will.


glaube das machen viele hier, also ist denen die performance nicht ganz egal.

gruß


----------



## fastjack (18. Mrz 2010)

@Dude Du sprichst mir aus der Seele. Wie gesagt, ich denke wir meinem am Ende fast alle dasselbe, nur läßt es sich im Forum deutlicher schwerer Ausdrücken als im Gespräch. In diesem Sinne 

Hast Du messbare Werte bekommen, als Du die Anzahl der Iterationen/Objekt erhöht hast ?


----------



## Dude123 (18. Mrz 2010)

hab es noch nicht öfters durchlaufen lassen.

müsste dazu noch änderungen vornehmen, denn momemtan ist alles noch so ausgelegt dass es nur einmal funktioniert ^^

finde auch eher wenig zeit, da ich noch viel für die schule machen muss und für die arbeit.

werde es aber die tage nochmal genauer testen ^^

und für alle die es interessiert. es geht hier um einen schlichten sudoku löser ^^ nicht mehr und nicht weniger

nur ist es kein einfacher zufalls/backtracking dingen, sondern da steck doch schon mehr dahinter ^^

ob es nun wieder sinn macht es zu optimieren sei dahin gestellt ^^ nur ich bin ja auch noch am lernen und dadurch lernt man erst richtig. so seh ich das ^^



gruß


----------



## bygones (18. Mrz 2010)

fastjack hat gesagt.:


> Mal eine kurze Frage an alle Performancekritiker: Wie groß war bisher Eure größte Serveranwendung, an der Ihr bis jetzt mitgearbeitet habt? Zwei Tabellen, drei, oder sogar gar keine Datenbank? 10 Datensätze, oder vielleicht sogar 100? Oder vielleicht überhaupt keine?!?!


keine - nix - nada... ich hab mein ganzes wissen allein von buechern und nie in Wirklichkeit ausprobiert. Ich habe weder als Reviewer zig tonnen code von anderen angeschaut noch als QSler diverse Codestellen von "performance" optimierten code angeschaut.
Mein Wissen ist rein theoretischer Natur und hat nix mit einem reellen Beispiel zu tun. Die ueber 10 Jahre Programmiererfahrung sind ebenso nur durch Unwissenheit gekommen

beat that - irony... (wenn schon geflamed wird dann bitte die richtigen)



fastjack hat gesagt.:


> @Dude Du sprichst mir aus der Seele. Wie gesagt, ich denke wir meinem am Ende fast alle dasselbe, nur läßt es sich im Forum deutlicher schwerer Ausdrücken als im Gespräch. In diesem Sinne


tun wir auch


----------



## fastjack (18. Mrz 2010)

@bygone
Du arbeitest nicht zufällig in Redmond oder ? (Spaß)


----------



## bygones (18. Mrz 2010)

fastjack hat gesagt.:


> @bygone
> Du arbeitest nicht zufällig in Redmond oder ? (Spaß)


wenn dann lieber Mountain View


----------

