Krishty hat geschrieben:Die Find All References- und View Call Hierarchy-Funktionen sind übrigens das Sinnloseste, was es gibt. Ich sehe bei Ersterem keinen Unterschied zu Seach in All Files (außer, dass es hundertmal lansamer ist) und Zweites wird in einem billigen 10k-Zeilen-Projekt trotz zwei voll ausgelasteten i7-Threads nie fertig …
Was auch unheimlich aussagekräftig ist – wir wissen ja, dass Java gerade im Hinblick auf seine endlosen Möglichkeiten der Metaprogrammierung und durch die hunderten Header, die am Anfang jeder Datei eingebunden werden, deutlich komplexer zu interpretieren und zu verwalten ist als C++.Chromanoid hat geschrieben:Versuchs mal mit Eclipse oder Netbeans. Eclipse schafft recht locker Projekte mit mehr als 4000 .java Dateien.
Zu 1.: WateXile hat geschrieben:Krishty hat geschrieben:Die Find All References- und View Call Hierarchy-Funktionen sind übrigens das Sinnloseste, was es gibt. Ich sehe bei Ersterem keinen Unterschied zu Seach in All Files (außer, dass es hundertmal lansamer ist) und Zweites wird in einem billigen 10k-Zeilen-Projekt trotz zwei voll ausgelasteten i7-Threads nie fertig …
- Find All References ist schneller als Search in All Files.
- Was passiert, wenn du Find All References machst und dann im Kontextmenü Resolve Results anwählst?
Ja das ist klar, dennoch würde mich das echt mal interessieren - schließlich haben beide IDEs guten Cpp Support. Mich würde einfach nur mal interessieren, wie sich so Eclipse oder Netbeans gegenüber MS VS schlägt...Krishty hat geschrieben:Was auch unheimlich aussagekräftig ist – wir wissen ja, dass Java gerade im Hinblick auf seine endlosen Möglichkeiten der Metaprogrammierung und durch die hunderten Header, die am Anfang jeder Datei eingebunden werden, deutlich komplexer zu interpretieren und zu verwalten ist als C++.Chromanoid hat geschrieben:Versuchs mal mit Eclipse oder Netbeans. Eclipse schafft recht locker Projekte mit mehr als 4000 .java Dateien.
Das mag für Java stimmen, für C++ eher nicht. CDT kriegt nichtmal die paar MiB Code auf Arbeit richtig indiziert (C-Code mit etwas C++) :roll:Chromanoid hat geschrieben:Versuchs mal mit Eclipse oder Netbeans. Eclipse schafft recht locker Projekte mit mehr als 4000 .java Dateien.
Naja Java ist ja nicht wirklich hipp :D Die coolen Kids nehmen Scala, Groovy, Ruby und Erlang. Achja LISP/Clojure und Haskell erfreuen sich auch wieder mehr Coolheit :). Und Python nicht vergessen ^^.Krishty hat geschrieben:Da liegt dann auch einer der wenigen Vorteile von hippen Sprachen wie Java.
Stimmt, wenn ich SiAF mehrmals benutze, wird es merklich schneller. Allerdings habe ich auch herausgefunden, dass FAR einem weniger Referenzen ausspruckt als SiAF. Das deckt sich mit der folgenden Aussage im Bezug auf die Anzahl durchsuchter Dateien:Krishty hat geschrieben:Zu 1.: Wat
Okay, bei der ersten Ausführung kann SiAF ein bisschen dauern. Danach sind es aber wirklich nur Hundertstelsekunden, während FAR jedes Mal zwei Sekunden lädt.
Bei meinen weiteren Tests, auch mit unterschiedlichen Suchtexten natürlich, hat dann SiAR dann doch weitaus besser abgeschnitten. Ich hatte zuvor nur die Suchzeit am Anfang, nicht aber die Suchzeit beim Expandieren der Baumstruktur beachtet. Mea Culpa. Aber dann ist die Aussage vom Program Manager nur Schwachsinn. Lug und Betrug überall.Raman Sharma, Program Manager on the VC++ team hat geschrieben:It’s worth mentioning that this search is unlike just searching for some text in the entire solution. This is because for this search, the C++ IDE uses an index to narrow the list of files to search. So it doesn’t look through all the files in the solution. The outcome is significantly better performance than just “Find in Files” (or grep), especially for large solutions.
Bei meinen Test gerade hat er auch Aufrufe in Initialisierungslisten gefunden (was dein Gegenbeispiel natürlich nicht den Rang abläuft). Was ergibt sich, wenn Hide Unconfirmed abgeschaltet wird? (Dies ist übrigens schreckliche Ausdrucksweise. Statt Hide Unconfirmed lieber Show Unconfirmed, sonst muss man bei „Hide Unconfirmed abgeschalten“ zweimal nachdenken.)Krishty hat geschrieben:Spuckt auch nur die Hälfte aus – wenn die Referenzen auf einen K’tor gesucht werden, werden keine Aufrufe durch Initialisierungslisten gefunden sondern nur der Bezeichner der Klasse gefolgt von einer passenden Parameterliste m(
Riecht für mich nach einem Fall für Connect. Zuvor müsste man ein Minimalbeispiel zusammenbekommen; das könnte hierbei schwierig werden. Hast du mal die Quellcodedatei genommen, mittels /P in Gänze gedumpt, in ein leeres Projekt eingebunden und noch einmal mittels FAR durchsucht? (Wenn du FAR in einer Header-Datei machst, könntest du eine beliebige Quellcodedatei, welche den Header einbindet, nehmen.) Wenn dann der Fehler immer noch auftaucht, könnte man die bis zu einem Minimalbeispiel abspecken.Krishty hat geschrieben:Hide Unconfirmed ändert auch nichts. Igitt.
Naja, kaum funktionierende Features sind keine "Frage des Geschmacks". Das ganze hängt auch extrem davon ab, wie groß das Projekt ist. Ideal wäre es, wenn Eclipse/CDT auf Arbeit wenigstens die 150MiB Code Minimalprojekt indizieren könnte. Aber nix da... Und wenn er doch mal "fertig" ist, funktioniert dann trotzdem kaum was, weil der Index Müll ist.Chromanoid hat geschrieben:Ich verstehe, Netbeans auch schon mal getestet? Ich entwickle ja fast ausschließlich Java und bin sehr zufrieden mit Eclipse und Netbeans. Ein kleiner C++ Ausflug mit Netbeans hat mir auch gut gefallen. Aber ohne ein großes C++ Projekt an dem man regelmäßig arbeitet, kann man eine IDE eben nicht auf C++ Tauglichkeit überprüfen. Auf der Suche nach der IDE "to rule them all" (Sprachen nicht andere IDEs ;)) bin ich da immer sehr an Meinungen interessiert.
Soweit ich mich erinnere war Stefan Zerbst zum Beispiel recht zufrieden mit Eclipse (http://zfx.info/viewtopic.php?f=4&t=1492&p=18265#p18265). Ich bräuchte noch ein paar mehr Stimmen um die Behauptung über Untauglichkeit, der ich schon oft begegnet bin, mehr Glauben schenken zu können :). Bisher riecht es für mich nach einer Frage des Geschmacks...
Code: Alles auswählen
// Packs eight characters of a zero-terminated string into a 64-bit unsigned integer.
explicit // has only one parameter
Identifier(
ASCIICharacter const * const toZeroTerminatedName
)
: myValue(0)
{
auto const numberOfCharacters(::strlen(toZeroTerminatedName));
assert(8 >= numberOfCharacters);
for(auto currentCharactersIndex(0u); currentCharactersIndex < numberOfCharacters; ++currentCharactersIndex) {
UInt8B const nextCharacter(charsetLookup(toZeroTerminatedName[currentCharactersIndex]));
myValue |= nextCharacter << (8 * currentCharactersIndex);
}
return;
}Nichts da, nichts da. Jetzt sehe ich, was passiert: Ist das Objekt statisch, wie inKrishty hat geschrieben:Und dabei kriegt dieser Drecks-Optimizer das ja noch nicht einmal aufgelöst, da er 64-Bit-Shifts nicht statisch auswerten kann. Echt mal, wtfNehme ich zurück! Er schreibt tatsächlich zweimal mov. Vor ein paar Tagen sah das noch anders aus, da musste ich ja auf zwei 32-Bit-Wörter ausweichen, damit er es optimieren konnte.
Die Leistung ist ohne SSE2-Intrinsics 23–76 % höher, abhängig vom BlickwinkeleXile vor langer Zeit im Anti-Jammer-Thread hat geschrieben:Wie schaut denn die Performance ohne die Intrinsics von XNA Math aus? Dazu einfach _XM_NO_INTRINSICS_ definieren, mich würde das Resultat sehr interessieren. :)Krishty hat geschrieben:XNA Math ist exzellent. Manche Funktion ist bei mir gegenüber selber dahingehackten Mathe-Routinen um 80 % eingebrochen … die Performance ist bei mir leider insgesamt nicht im messbaren Bereich, aber wenn die Ausführungszeit nur halb so viel geschrumpft ist wie die Kompilatgröße, ist das fantastisch. Dafür ist MS aus meiner Alignment-Missgunst fast schon wieder raus.
Vielleicht liegt das an den (Standard)Einstellungen oder am Code oder an Eclipse 3.6, was wir hier einsetzen. Keine Ahnung. Die Einstellungen sind auf Standard, bis auf 6GiB RAM für das Index-File. 16GiB hat die Kiste hier verbaut, sollten reichen.Lynxeye hat geschrieben:Hier muss ich jetzt auch mal einhaken. Eclipse mag man ja vieles anlasten, aber es ist die einzige IDE, die es schafft den kompletten Linuxkernel zu indizieren und mir daraus sinnvolle Vorschläge zu präsentieren. Eclipse ist damit wieder meine Lieblings IDE für C Entwicklung, da mein Vorheriger Favorit Code::Blocks zwar wunderbar zu bedienen ist, aber bei zu vielen zu indizierenden Dateien hoffnungslos die Hufe hochreisst.
GVIM mit cscope schafft das zwar auch, ist für meine Arbeitsabläufe aber nicht halb so effektiv.
Und natürlich frisst Eclipse bei großen Projekten RAM wie kleine, saftige Kinder, aber RAM ist billig.
