| Aber ein aktuelles Gnome ist arsch langsam, umsonst gehts im Artikel nicht drum, dass man 7s Sparen kann, wie geht das, wenn bei dir Gnome schon in 2-3s startet. Das kommt halt drauf an, wie aufgeblasen die Distribution ist. Bei mir ist GNOME 2.12.1 in Verwendung und wenn ich beim GNOME-Start 7 Sekunden sparen könnte, müsste der GNOME-Desktop schon vor dem Login da sein. Wenn ich z.B. ne SUSE starte, könnte man annehmen, dass der Start von Linux 1-2 Minuten dauert. Mit ner anderen Distribution oder gar anderem Init-System sieht die Sache ganz anders aus. Genauso Eclipse: Manche halten Java für furchtbar langsam. Bei mir startet Eclipse nicht langsamer als KDevelop, unter KDE wohlgemerkt, sonst kommst du mir noch mit dem Aufbau des System-Config-Caches. ;-)
| Ich muss nur zwei Live CDs nehmen, einmal Gnome einmal KDE und man sieht, was sache ist. KDE ist beim Start nur dann schneller, wenn mit Prelinking etc. getrickst wird.
>>>>Genauso Eclipse: Manche halten Java für furchtbar langsam. Bei mir startet Eclipse nicht langsamer als KDevelop, unter KDE wohlgemerkt, sonst kommst du mir noch mit dem Aufbau des System-Config-Caches
Ja und an was wird das wohl liegen:-)
Eclipse ist teilweise keine Java Bytecode mehr sondern native Code, daher gibts auch ein Paket für Windows und eins für Linux und guck mal ins eclipse directory da liegt kein eclipse.jar sondern ein eclipse binary:-) Für die Eclipse GUI wird auch kein AWT oder Swing genutzt, also warum vergleichst du eclipse mit anderen konventionellen Java Programmen?
Ich würde sagen, du hast dich jetzt ziemlich blamiert.
>>>>KDE ist beim Start nur dann schneller, wenn mit Prelinking etc. getrickst wird.
Was hat das mit tricksen zu tun, ein Trick wäre das weglassen von Funktionen.
Nur das bisschen Oberfläche ist kein Java-Bytecode, der Rest hingegen schon. Wer sich hier blamiert, sind diejenigen, die behaupten, Java wäre langsam, wobei es tatsächlich Swing ist, was jedes Widget aus der JavaVM heraus zeichnet, statt die Aufgabe den nativen Grafikbibliotheken zu überlassen. Aber das ändert sich ja mit J2SE 6.0, wenn Swing unter Windows die UxTheme.dll und unter Linux die libgtk-2.0.so nutzen wird.
Dass Eclipse eine Java-Anwendung ist, spüre ich im Betrieb jedes Mal, wenn der Virenscanner mal wieder die JAR-Archive durchcheckt. Richtig unergonomisch ist das, wenn man ein Projekt vom CVS-Server ausscheckt. Visual Studio läuft dort schneller (eben weil es da keine JAR-Dateien gibt).
Prelinking hat insofern etwas mit tricksen zu tun, dass es einige Nebenwirkungen hat, weshalb es manchmal auch notwendig ist, das Prelinking rückgängig zu machen oder zumindest einige Bibliotheken vom Prelinking auszunehmen. Wine hatte glaub ich mal tierische Probleme mit Prelinking.
Das kommt halt drauf an, wie aufgeblasen die Distribution ist. Bei mir ist GNOME 2.12.1 in Verwendung und wenn ich beim GNOME-Start 7 Sekunden sparen könnte, müsste der GNOME-Desktop schon vor dem Login da sein.
Wenn ich z.B. ne SUSE starte, könnte man annehmen, dass der Start von Linux 1-2 Minuten dauert. Mit ner anderen Distribution oder gar anderem Init-System sieht die Sache ganz anders aus.
Genauso Eclipse: Manche halten Java für furchtbar langsam. Bei mir startet Eclipse nicht langsamer als KDevelop, unter KDE wohlgemerkt, sonst kommst du mir noch mit dem Aufbau des System-Config-Caches. ;-)
| Ich muss nur zwei Live CDs nehmen, einmal Gnome einmal KDE und man sieht, was sache ist.
KDE ist beim Start nur dann schneller, wenn mit Prelinking etc. getrickst wird.
Ja und an was wird das wohl liegen:-)
Eclipse ist teilweise keine Java Bytecode mehr sondern native Code, daher gibts auch ein Paket für Windows und eins für Linux und guck mal ins eclipse directory da liegt kein eclipse.jar sondern ein eclipse binary:-)
Für die Eclipse GUI wird auch kein AWT oder Swing genutzt, also warum vergleichst du eclipse mit anderen konventionellen Java Programmen?
Ich würde sagen, du hast dich jetzt ziemlich blamiert.
>>>>KDE ist beim Start nur dann schneller, wenn mit Prelinking etc. getrickst wird.
Was hat das mit tricksen zu tun, ein Trick wäre das weglassen von Funktionen.
Wer sich hier blamiert, sind diejenigen, die behaupten, Java wäre langsam, wobei es tatsächlich Swing ist, was jedes Widget aus der JavaVM heraus zeichnet, statt die Aufgabe den nativen Grafikbibliotheken zu überlassen.
Aber das ändert sich ja mit J2SE 6.0, wenn Swing unter Windows die UxTheme.dll und unter Linux die libgtk-2.0.so nutzen wird.
Dass Eclipse eine Java-Anwendung ist, spüre ich im Betrieb jedes Mal, wenn der Virenscanner mal wieder die JAR-Archive durchcheckt. Richtig unergonomisch ist das, wenn man ein Projekt vom CVS-Server ausscheckt. Visual Studio läuft dort schneller (eben weil es da keine JAR-Dateien gibt).
Prelinking hat insofern etwas mit tricksen zu tun, dass es einige Nebenwirkungen hat, weshalb es manchmal auch notwendig ist, das Prelinking rückgängig zu machen oder zumindest einige Bibliotheken vom Prelinking auszunehmen. Wine hatte glaub ich mal tierische Probleme mit Prelinking.