Java kleinste Zeiteinheit

[Dude123]

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]

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

 

[function]

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

 

[The_S]

Solche Microbenchmarks sind ohnehin nicht sehr Aussagekräftig.

 

[SlaterB]

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-]

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

Der einzig sinnvolle Weg.

 

[Dude123]

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]

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]

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]

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]

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

 

[bygones]

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

rofl

 

[Ark]

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]

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]

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

eben, üblicherweise

 

[-MacNuke-]

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]

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]

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]

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]

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

 

[maki]

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]

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]

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]

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]

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]

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]

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

 

[maki]

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]

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

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]

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

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 ?

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

ala

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

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

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]

>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]

@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]

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 ß

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]

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]

>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)

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

@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.

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]

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

 

[Dude123]

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]

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]

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]

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]

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]

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]

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.

[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]

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]

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]

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]

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]

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]

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]

@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.