Die schnellste Collection-Klasse ?

[centrax]

Hallo Forum,

Ich arbeite zur Zeit an einem Projekt, bei dem ich sehr auf Laufzeit achten muss. Und da ich auch sehr viel mit Collections arbeite, ist fuer mich wichtig, mit welcher Collection-Klasse man am schnellsten arbeiten kann; instanziieren kann auch länger dauern, wichtig is das Abrufen der einzelnen Mitglieder.

Bis jetzt hab ich die ArrayList genommen.
War das ne kluge Wahl oder gibts was besseres?

liebe Grüße,
centrax

 

[Landei]

Kommt ganz darauf an, was du machen willst. Um z.B. schnell herauszufinden, ob ein Objekt in einer Collection ist, ist ein HashSet "schnell", viel schneller als eine ArrayList. Brauchst du indizierten Zugriff, hilft dir das Set nicht. ArrayList ist schnell, wenn nur hinten angefügt oder gelöscht wird, und das Befüllen geht auch schnell, wenn man sie schon mit der ungefähren Endgröße initialisieren kann. LinkedList ist gut, wenn auch am Anfang oder in der Mitte eingefügt oder gelöscht werden soll, und wenn die Elemente immer nacheinander abgefragt werden (also über Iterator und nicht über Index).

 

[ice-breaker]

ArrayList ist schnell, wenn nur hinten angefügt oder gelöscht wird

eigentlich ist da doch auch die LinkedList schneller
ArrayList wird eben benötigt bei wahlfreiem Zugriff, sollte man den nicht benötigen, ist man eigentlich mit einer LinkedList immer besser beraten (Anmerkung: sofern es eine Liste sein soll, das HashSet-Argument zeigt ja, dass die Liste nicht immer optimal ist)


Mir fällt da noch die Javaloutions-Collection ein, die behaupten ja schneller als die Original-Collection zu sein, ob das stimmt, weiß ich nicht, ich habe mir den Sourcecode noch nie angesehen.

 

[Gast2]

google-collections - Project Hosting on Google Code sind auch ein Blick wert.

 

[Meldanor]

ArrayList verwende ich immer dann, wenn ich was geladen haben und mehr als einmal auf ein Objekt zugreife. Beispiel hier wäre ein Vergleich von zwei Listen, wo ich jedes Element der 1. Liste mit jedem Element der 2. Liste vergleiche. Da lohnt es sich, eine ArrayListe zu haben, da die Komplexität zum Indezierten Zugriff bei O(1) liegt.
LinkedList verwende ich immer dann, wenn ich Sachen nur temporär zwischenspeicher.
Am Beispiel von eben:
Ich habe zwei Listen, die einen verschiedenen Datenbestand haben. Nun schaue ich mir beide in einer for-Schleife an und möchte mir z.B. alle Elemente zwischenspeichern, die in Liste 1 vorkommen, aber nicht in Liste 2.
Solche Elemente füge ich der LinkedList zu, da ein Hinzufügen zu einer LinkedList gerade mal O(1) benötigt, bei einer ArrayList jedoch O(n), da das interne Array eventuel vergrößert werden muss durch Erzeugung eines neuen mit größeren Speicher und dann müssen alle Elemente des alten Arrays umkopiert werden.
Um dann von der LinkedList die Elemente auszuwerten, greife ich in einer while-Schleife auf das erste zu, verarbeite das irgendwie und lösche dann das erste Element. Dabei hab ich immer eine Komplexität von O(1).
Andere Collections habe ich selber noch nicht gebraucht.

 

[centrax]

Erstmal danke für die ganzen Antworten!

Also ich brauche weder indizierte Zugriffe noch vergleiche, ich sammle einfach nur Objekte, und gehe die in deer erweiterten for()-Schleife seeeehr sehr oft ab. Das Hinzukommen soll nur Anfangs sein, da is Laufzeit irrelevant und auch das Löschen von Elementen wird fast ueberhaupt nicht gebraucht, ich muss nur Objekte aneinanderreihen und diese oft abgehen. Natuerlich wäre ein Array ganz praktisch, aber es muss trotzdem jederzeit ein neues Element hinzugefügt werden können.
Also, was wäre hierfür besser? ArrayList oder LinkedList?

 

[fjord]

What is faster - LinkedList of ArrayList?

 

[ice-breaker]

ich sammle einfach nur Objekte, und gehe die in deer erweiterten for()-Schleife seeeehr sehr oft ab. [...] ich muss nur Objekte aneinanderreihen und diese oft abgehen.

also ehrlich gesagt klingt es sehr unrealistisch, dass du einfach in einer for-Schleife nur über das Array iterierst, es seidenn du hast eine MEthode mit der Komplexität O(n^2) oder O(n^3)

Natuerlich wäre ein Array ganz praktisch, aber es muss trotzdem jederzeit ein neues Element hinzugefügt werden können.
Also, was wäre hierfür besser? ArrayList oder LinkedList?

bei jeder der Listen kannst du dauernd was dazufügen und darüber iterieren.
Ich vermute auch mal, dass die wirklich so gut wie keinen Unterschied haben werden (Microbenchmarks aussen vorgelassen)
Aber es klingt für mich immernoch so, dass da irgendetwas nicht stimm.

What is faster - LinkedList of ArrayList?

Microbenchmarks sind natürlich eine sehr feine Sache :noe:
Wenn bei einer Laufzeit von 700-1200ms mal der Garbage Collector oder JIT-Compiler anspringt ist das ganze Ergebnis absolut verfälscht, auf die Messergebnisse da kann man nichts geben.
beginning und middle stimmen zwar, decken sich mit dem Konzept, bei end bin ich mir aber nicht sicher, da dürfte es imho eigentlich fast keinen Unterschied geben.

 

[centrax]

also ehrlich gesagt klingt es sehr unrealistisch, dass du einfach in einer for-Schleife nur über das Array iterierst

Also ich iteriere ueber die automatische for()-Schleife, also sinngemäß so:

ArrayList<Object> liste;
for(Object o : liste) {
    //Hier mach ich dann was mit den Objekten, hier zB:
    System.out.println(o.toString());
}

Natürlich mach ich das dann nich mit Object sondern mit meiner eigenen Klasse und nich mit der Methode^^

 

[Guybrush Threepwood]

Hi,
gerade noch bei JavaInsel zur Debatte ArrayList vs. LinkedList gesehen:

java.util.concurrent.CopyOnWriteArrayList. Schnelle Liste, optimal für häufige nebenläufige Lesezugriffe

(Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 12.3 Listen).
Ich habe allerdings noch nie damit gearbeitet.

 

[Marco13]

Die verwende ich hauptsächlich für Listener: Die werden u.U. OFT benachrichtigt, aber selten hinzugefügt/entfernt (und mit der CopyOnWriteArrayList können z.B. auch in den Listener-Methoden neue Listener zum Event-Werfer hinzugeügt werden, ohne, dass es dann gleich kracht)

 

[centrax]

Das hört sich gut an.
Habs schonmal sporadisch eingebaut, is merkbar noch keine Änderung, aber ich hab das Programm auch noch nicht grossen Belastungen ausgesetzt, das kommt aber noch.
Auf jeden Fall vielen Dank an alle!

 

[FArt]

Das hört sich gut an.
Habs schonmal sporadisch eingebaut, is merkbar noch keine Änderung, aber ich hab das Programm auch noch nicht grossen Belastungen ausgesetzt, das kommt aber noch.
Auf jeden Fall vielen Dank an alle!

Leider bin ich zu spät mit meinem Tipp:
1. Optimiere nur, wenn es nötig ist.
2. Optimiere nur, wenn du (über Meßwerte) weißt, wo du optimieren musst.
3. Optimiere nur, wenn du einen signifikante Verbesserung erwartest.

Alles andere ist verschwendete Zeit und Geld (s.o.)

 

[ARadauer]

Leider bin ich zu spät mit meinem Tipp:
1. Optimiere nur, wenn es nötig ist.
2. Optimiere nur, wenn du (über Meßwerte) weißt, wo du optimieren musst.
3. Optimiere nur, wenn du einen signifikante Verbesserung erwartest.

Alles andere ist verschwendete Zeit und Geld (s.o.)

Wer sagt das? :rtfm: Martin Fowler?

Ich weiß das das eine Lehrmeinung ist, aber ich stimme da überhaupt nicht zu!

Wann ist es nötig? Wenn mein Kunde zur Konkurenz gewechselt ist, weil meine Software träge ist? :autsch:

 

[kama]

Hallo,

Leider bin ich zu spät mit meinem Tipp:
1. Optimiere nur, wenn es nötig ist.
2. Optimiere nur, wenn du (über Meßwerte) weißt, wo du optimieren musst.
3. Optimiere nur, wenn du einen signifikante Verbesserung erwartest.

Alles andere ist verschwendete Zeit und Geld (s.o.)

Dem kann ich 100%ig zustimmen...da wird in vielen Projekten viel Zeit verschwendet, weil einige "Meinen man hätte ein Performance Problem" OHNE aber gemessen zu haben...erlebe ich sehr oft...und hinter her stellt sich dann oft raus, dass das Problem ganz wo anders liegt oder man gar kein Problem hat

Gruß
Karl Heinz Marbaise

 

[FArt]

Wer sagt das? :rtfm: Martin Fowler?

Ich weiß das das eine Lehrmeinung ist, aber ich stimme da überhaupt nicht zu!

Wann ist es nötig? Wenn mein Kunde zur Konkurenz gewechselt ist, weil meine Software träge ist? :autsch:

Wieso? Ist es mehr oder weniger wert, wenn es Martin Fowler sagt? Das sagt der gesunde Menschenverstand und es zeigt die Erfahrung.

Wenn du feststellst, dass deine Software träge ist, wenn sie beim Kunden ist, hast du ganz andere Probleme... z.B. schlechte Entwickler, fehlende nichtfunktionale Anforderungen bei der Beauftragung, keine oder schlechteTests, keine oder schlechte QS, ... u.v.m.

 

[maki]

Wer sagt das? :rtfm: Martin Fowler?

Ich weiß das das eine Lehrmeinung ist, aber ich stimme da überhaupt nicht zu!

Wann ist es nötig? Wenn mein Kunde zur Konkurenz gewechselt ist, weil meine Software träge ist? :autsch:

Das ist die Lehrmeinung & Meinung in der Realität, die seit den 70er jahren verbreitet & akzeptiert ist, die heute auch noch wahr ist, aber manche Leute schaffen es immer noch nicht es zu verstehen

Wenn du den Text nochmals genau liest, wirst du sehen, dass dort erklärt wird was Performance Verbesserungen sind und wann & wie sie angewendet werden sollten.
Du könntest ja jetzt mal genau den Satz raussuchen, die dir nicht gefällt, dann könnte man den diskutieren

Donald Knuth sagt dir ja wohl etwas, oder?

# “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.” - W.A. Wulf

# “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified”[6] - Donald Knuth

# “Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is.” - Rob Pike

# “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

 

[Ark]

Ich bin ja im Wesentlichen der Meinung von ARadauer. (Und jetzt schlagt mich. )

Die Kunst besteht mE darin, gar nicht erst Software zu schreiben, von der man weiß, dass sie langsam ist. Oder anders herum: Wenn ich sehe, dass ich etwas schneller/performanter schreiben könnte, dann schreibe ich das gleich mal so und warte eben nicht darauf, dass das zu einem Performanceproblem ausartet.

Dabei meine ich jetzt nicht, dass man möglichst unverständlichen da "optimierten" Code schreiben soll. Aber wenn ich bereits beim Entwurf(!) sehe, dass ich die Wahl zwischen O(n²) und O(n log n) habe, dann versuche ich doch, mir die O(n log n)-Option wenigstens offenzuhalten, indem ich entsprechend abstrahiere bzw. entwerfe. Auf keinen Fall würde ich Software so entwerfen, dass sie bewusst langsam ist; im Sinne von: Beim Entwurf wäre mir bewusst, dass es auch um Größenordnungen schneller hätte gehen können.

Die Lehrmeinung ist wohl auch, dass man Code nach Möglichkeit wiederverwenden soll. Wenn ich mich aber bewusst für die schlechtere O(n²)-Option entscheide, dann sage ich damit auch, dass ich gar nicht will, dass mein Code oft wiederverwendet wird.

Ich denke, dass es einen Zusammenhang zwischen der Wiederverwendbarkeit und der Performance eines Codes gibt: Je performanter ein Code ist, desto öfter möchte er eingesetzt bzw. wiederverwendet werden. Einweg-Code ist per definitionem nicht auf Wiederverwendbarkeit ausgelegt; und dazu gehören auch gewisse Qualitäten in Sachen Performance.

Ark

 

[FArt]

Die Kunst besteht mE darin, gar nicht erst Software zu schreiben, von der man weiß, dass sie langsam ist. Oder anders herum: Wenn ich sehe, dass ich etwas schneller/performanter schreiben könnte, dann schreibe ich das gleich mal so und warte eben nicht darauf, dass das zu einem Performanceproblem ausartet.

Dabei meine ich jetzt nicht, dass man möglichst unverständlichen da "optimierten" Code schreiben soll. Aber wenn ich bereits beim Entwurf(!) sehe, dass ich die Wahl zwischen O(n²) und O(n log n) habe, dann versuche ich doch, mir die O(n log n)-Option wenigstens offenzuhalten, indem ich entsprechend abstrahiere bzw. entwerfe. Auf keinen Fall würde ich Software so entwerfen, dass sie bewusst langsam ist; im Sinne von: Beim Entwurf wäre mir bewusst, dass es auch um Größenordnungen schneller hätte gehen können.

Die Lehrmeinung ist wohl auch, dass man Code nach Möglichkeit wiederverwenden soll. Wenn ich mich aber bewusst für die schlechtere O(n²)-Option entscheide, dann sage ich damit auch, dass ich gar nicht will, dass mein Code oft wiederverwendet wird.

Ich denke, dass es einen Zusammenhang zwischen der Wiederverwendbarkeit und der Performance eines Codes gibt: Je performanter ein Code ist, desto öfter möchte er eingesetzt bzw. wiederverwendet werden. Einweg-Code ist per definitionem nicht auf Wiederverwendbarkeit ausgelegt; und dazu gehören auch gewisse Qualitäten in Sachen Performance.

Ark

Unterscheide sinnvolle Implementierung (nach Anforderungen!) gegen Optimierung.
"Performance" ist immer relativ. Es gibt keine pauschal gute Implementierung. Es gibt nur gute Implementierungen für konkrete Probleme und Anforderungen.

 

[maki]

Ich bin ja im Wesentlichen der Meinung von ARadauer. (Und jetzt schlagt mich. )

Leider hat ARadauer euigentlich nur gesagt, dass er gegen Optimierungen ist, zumindest bis jetzt

Aber da du ja deine Meinung kund tust..

Die Kunst besteht mE darin, gar nicht erst Software zu schreiben, von der man weiß, dass sie langsam ist. Oder anders herum: Wenn ich sehe, dass ich etwas schneller/performanter schreiben könnte, dann schreibe ich das gleich mal so und warte eben nicht darauf, dass das zu einem Performanceproblem ausartet.

das ist der Knackpunkt, du kannst von vornherein gar nicht wissen was langsam bzw. schneller ist, höchstens in Ausnahmefällen weiss man was wirklich relevant ist.

Dabei meine ich jetzt nicht, dass man möglichst unverständlichen da "optimierten" Code schreiben soll. Aber wenn ich bereits beim Entwurf(!) sehe, dass ich die Wahl zwischen O(n²) und O(n log n) habe, dann versuche ich doch, mir die O(n log n)-Option wenigstens offenzuhalten, indem ich entsprechend abstrahiere bzw. entwerfe. Auf keinen Fall würde ich Software so entwerfen, dass sie bewusst langsam ist; im Sinne von: Beim Entwurf wäre mir bewusst, dass es auch um Größenordnungen schneller hätte gehen können.

Um dein Beispiel aufzugreifen:
O(n²) vs. O(n log n)
Hört sich super an, sagt aber gar nix über die Performance aus, da fehlt nämlich das wichtigste... der Kontext.

Wenn während dem ganzen Programm dieser Algorythmus nur ein einziges mal auf 2 Elemente angewendet wird, ist es irrelevant ob O(n²) oder O(n log n), die "Optimierungen" würden wohl im Microsekundenbereich liegen -> nicht relevant
Deswegen erst messen was relevant ist, danach optimiert man die relevanten Teile, und diese Optimierungen müssen auch wieder überprüft werden, ob sie denn das gewünschte Ergebniss gebracht haben.

Die 80/20 regel zu ingorieren fürt immer dazu, dass der Code sehr schlecht wird, aber cniht unbedingt schneller, nur darum geht es beim optimieren: Messbare Optimierungen, die anderen sind keine.

Die Lehrmeinung ist wohl auch, dass man Code nach Möglichkeit wiederverwenden soll. Wenn ich mich aber bewusst für die schlechtere O(n²)-Option entscheide, dann sage ich damit auch, dass ich gar nicht will, dass mein Code oft wiederverwendet wird.

Das ist nicht die Lehrmeinung, dass kommt aus der Realität, Perfomace ist selten wichtiger als Wartbarkeit, ltzteres kostet nämlich richtig Geld, dafür könnte man oft auch schnellere Hardware kaufen.

Ich denke, dass es einen Zusammenhang zwischen der Wiederverwendbarkeit und der Performance eines Codes gibt: Je performanter ein Code ist, desto öfter möchte er eingesetzt bzw. wiederverwendet werden. Einweg-Code ist per definitionem nicht auf Wiederverwendbarkeit ausgelegt; und dazu gehören auch gewisse Qualitäten in Sachen Performance.

In der Realität geht es darum, dass der Code das macht was er soll, dass er verständlich ist und Doku hat, wenn er dann noch Performant ist ist das gut.

 

[fastjack]

Falls es um Laufzeiten geht, mußt Du Dich mit der O-Notation anfreunden (The Big-Oh). Wenn es nur um Zeitmessungen geht, kannst Du so etwas ganz einfach mit QuickBench benchen.

http://www.java-forum.org/blogs/fastjack/125-benchmarking.html

 

[FArt]

Microbenchmarks bilden nur einen sehr geringen Teil reeller Softwareperformance ab. In der Regel ist Performance ein Tradeoff zwischen Geschwindigkeit und Speicherverbrauch und hängt ab von Randparametern wie der verwendete Kontext, konkurrierende Zugriffe, GC, Optimierungen des Hotspotcompilers, ..... uvm.

Die beste Lösung ist die einfachste, vom Design her sauberste Lösung, die die Anforderungen erfüllt. Diese ist schnell implementiert, seltener fehleranfällig, besser zu warten und bietet somit die größte Wertschöpfung. Von "Performance" kann sich weder der Arbeitgeber noch der Kunde was kaufen ;-)

[EDIT]
Oh, fastjack hat sein Posting abgeändert... na ja, meine Aussage passt immer noch...

Postings in Foren ändern zu können ist ein #%§"!?/&%* Feature...

 

[fastjack]

[EDIT]
Oh, fastjack hat sein Posting abgeändert... na ja, meine Aussage passt immer noch...

Ja, sry, ich wußte nicht, daß Du schon am schreiben warst. Es war mir nur nicht ganz klar, was er unter Laufzeit versteht (O, oder Zeit). Das habe ich geändert.

Von "Performance" kann sich weder der Arbeitgeber noch der Kunde was kaufen

Würde der Kunde dann wohl auch nicht, wenn es nicht performant läuft

 

[fastjack]

Trotzdem gebe ich Dir bei den anderen Aussagen recht

 

[bygones]

Performanceoptimierung im Betracht von O ist was für Theoretiker wie Ark.

Ansonsten stimme ich der richtigen Seite zu .... Mit einem fadenscheinigen Argument eine Optimierung reinzubauen ist in vielen Fällen kontraproduktiv. Schlussendlich läuft man Gefahr komplexeren Code zu haben der dann im System vielleicht (!) schneller läuft, dafür aber Wartungstechnisch ne Hölle ist.

Es wird selten verstanden - was Fart schon sagte - dass es ein Unterschied gibt zwischen bewusst sinnvoller Implementierung und Optimierung.

 

[maki]

...
Würde der Kunde dann wohl auch nicht, wenn es nicht performant läuft

Hatte noch nie einen Kunden, dem Performanz wichtiger war als ein funktionierendes Produkt
Die höchste Priorität hat nie die Performance.

 

[bygones]

Hatte noch nie einen Kunden, dem Performanz wichtiger war als ein funktionierendes Produkt
Die höchste Priorität hat nie die Performance.

jo - weil eben nur Theoretiker n Kollaps bekommen, wenn sie die Performance um 1,4% steigern konnten....

und wenn das Produkt bei einer Suche statt normalerweise 10s auf einmal 10min braucht, dann hat man bei weitem kein "Optimierungsproblem"

 

[FArt]

Hatte noch nie einen Kunden, dem Performanz wichtiger war als ein funktionierendes Produkt

... oder ein Gimmick-Feature ... auch Kunden wollen Spaß haben.

echtes Beispiel aus dem wahren Leben:
Suche über eine Datenstruktur im Speicher. Anforderung kleiner 1s. Der Maximalwert lag gemessen bei 0.8 s. Der Entwickler hatte eine Optimierung im Kopf (es hat sich im Nachhinein gezeigt, dass diese Optimierung die Maximaldauer auf die Hälfte reduzierte). GesamtMEHRaufwand (Verifizierung, Implementierung, Tests, QS, ...) nur 1PT (also nichts).
Er entschied sich für die erste Version ein niederpriores Feature umzusetzen, Gemsamtaufwand ca. 1 PT. Das war ein Gimmick-Feature, also ohne direkten Nutzen.

Die schnellere Suche fiel den Kunden nie auf. Das Gimmick-Feature schon und zwar ab der ersten Version. Der Mehrwert und die Akzeptanz der Software ist somit nicht über die Performance gesteigert worden, sondern über ein Feature, das normalerweise bei Zeitdruck nicht oder später realisiert wird.

 

[Ark]

Ansonsten stimme ich der richtigen Seite zu .... Mit einem fadenscheinigen Argument eine Optimierung reinzubauen ist in vielen Fällen kontraproduktiv.

(Jetzt kommt es wohl sehr darauf an, was man unter "Optimierung" versteht.) Dem stimme ich zu. Aber ich bin auch der Meinung, dass man Software zumindest so entwerfen sollte, dass man noch eine Möglichkeit zur "Optimierung" hat.

Ark

 

[maki]

(Jetzt kommt es wohl sehr darauf an, was man unter "Optimierung" versteht.) Dem stimme ich zu. Aber ich bin auch der Meinung, dass man Software zumindest so entwerfen sollte, dass man noch eine Möglichkeit zur "Optimierung" hat.

Ark

Eben

und je weniger "Optimierungen" ich am Anfang einbaue, umso einfacher ist es später zu optimieren. Klingt komisch, is aber so...
Bitte nicht vergessen, "Optimieren" bezieht sich immer auf etwas exisiterendes.

 

[fastjack]

Es kommt wohl eher drauf an, was Centrax machen soll/muß. Wenn sein Projektchef schon so auf Performance Wert legt, kann er sich wohl nicht hinstellen und sagen, daß das für ihn jetzt keine Prio hat. Ansonsten komme ich da auch mal gerne arbeiten

 

[maki]

Es kommt wohl eher drauf an, was Centrax machen soll/muß. Wenn sein Projektchef schon so auf Performance Wert legt, kann er sich wohl nicht hinstellen und sagen, daß das für ihn jetzt keine Prio hat. Ansonsten komme ich da auch mal gerne arbeiten

Hat dieser Projektchef eigentlich keine anderen Sorgen?
Wie zB. Deadlines, Funktionsumfang, Requirements, QA, Stabilität, usw.; die wichtigen Dinge eben.

Hatte es auch schon öfters das ein Teamchef/Projektleiter Performance für sehr wichtig gehalten hatte (da ging es einmal um ein Similatorframework für Drohnen/Flugzeuge, timing war immens wichtig... anfangs), bis er dann irgendwann merkte, das nutzt alles nix, wenn er kein lauffähiges Produkt hatte zur Deadline.

 

[FArt]

Es kommt wohl eher drauf an, was Centrax machen soll/muß. Wenn sein Projektchef schon so auf Performance Wert legt, kann er sich wohl nicht hinstellen und sagen, daß das für ihn jetzt keine Prio hat. Ansonsten komme ich da auch mal gerne arbeiten

Tja, bei moderneren Entwicklungsmethoden legt der Produktverantwortliche für Einzelpunkte Prioritäten fest und das Team entscheidet, was wann umgesetzt wird. Da arbeitet es sich sehr viel angenehmer als wenn man Entscheidungen umsetzen muss, die man nicht mittragen kann.

 

[fastjack]

Mich mußt Du nicht fragen, ich weis nicht, wie es ist ....

Apropos Optimierungen weglassen, um später zu optimieren (ich meine jetzt nicht irgendein micro-Zeugs). Da kommt bei mir immer eine böse Erinnerung auf. Ich kannte einen Architekten, der Sachen mit Absicht so augebaut hat, das sie spürbar sch**** laufen. Dannach hat er sich damit gebrüstet die Teile deutlich zu optimieren, natürlich mußte man dafür "auch" die Codestücke anderer angepasst werden, die DB optimiert werden usw. Rausgekommen ist es erst, nachdem sich auch andere Entwickler für seinen Code interessierten ... Ich habe das ganze BadBoy-Optimierung getauft. :lol:

 

[fastjack]

Mich mußt Du nicht fragen, ich weis nicht, wie es ist ....

also da wo Centrax ist

 

[FArt]

Mich mußt Du nicht fragen, ich weis nicht, wie es ist ....

Apropos Optimierungen weglassen, um später zu optimieren (ich meine jetzt nicht irgendein micro-Zeugs). Da kommt bei mir immer eine böse Erinnerung auf. Ich kannte einen Architekten, der Sachen mit Absicht so augebaut hat, das sie spürbar sch**** laufen. Dannach hat er sich damit gebrüstet die Teile deutlich zu optimieren, natürlich mußte man dafür "auch" die Codestücke anderer angepasst werden, die DB optimiert werden usw. Rausgekommen ist es erst, nachdem sich auch andere Entwickler für seinen Code interessierten ... Ich habe das ganze BadBoy-Optimierung getauft. :lol:

Wo waren da die Architektur- und Codereviews? *duck-und-weg*

:bae:

 

[fastjack]

Naja, wenn alles über einen (gottgleichgestellten) Architekten geht, der reviewt halt alles selbst am Wochenende und am liebsten die Sachen der anderen, so einfach ist das !

 

[fastjack]

Da man nicht mehr ändern darf:

letztes Posting war ironisch gemeint