Hallo Thierry, Am Fr, den 13.02.2004 schrieb Thierry de Coulon um 11:26: ...

...

1. Ist es normal, dass OpenOfficeWriter beim Öffnen 1 Minute und 58 Sekunden benötigt?

Nein.

... Kann man da was verschnellern?

Ja. Siehe unten.

Welche Version? OOo ist zwar nie schnell beim Start, aber bei mir (Doppel Athlon MP 1800+) dauerte es genau 5 Sekunden (wobei ich OOo schnon einmal gestartet hatte heute Morgen, was glaube ich die Sache verbessert, beim ersten Start muss das Programm wohl irgendwas wichtiges tun...)

Vergleich zu meinem System: Athlon 1400 mit 1,25GB RAM: OpenOffice 1.1.0 mit den Ximian Patches startet beim ersten Mal in unter 10 Sekunden und jedes weitere Mal in unter 5 Sekunden. Gut zu wissen, dass sich ein Dualsystem für OOo nicht wirklich lohnt ;-)

Meine Version ist OpenOffice.org 1.1 - diese Version ist VIEL schneller beim Start als alle 1.0.x Versionen.

Das kann ich nur bestätigen. Allerdings ist der angepasste Build von Ximian wirklich eine Empfehlung wert. Vielleicht gibt es mittlerweile sogar ja SuSE RPMs. Schließlich ist Ximian ja jetzt mit SuSE verwandt :-)

...

2. Das Drucken von Dateien z.B. Textdateien von OpenOfficeWriter dauert auch sehr lange. Kann man hier was verbessern?

Wie schaut das in anderen Anwendungen aus? Siehe unten.

Auch hier habe ich kein Problem gesehen. womit druckst du (cups?). Bei reine Textdateien sollte alles sehr schnell sein.

Drucken sollte unabhängig vom Inhalt (nicht Größe) schnell gehen. Ein paar nützliche Tips für OOo: 1. Selber bauen. Ich habe mir OOo selbst übersetzt (bzw. Portage hat das gemacht :-)). Vorher habe ich einfach die Binaries von openoffice.org benutzt. Im Vergleich habe ich etwas (2-3 Sekunden) schnellere Ladezeiten herausholen können. 2. Die Ximian Patches einbinden. Ximian bietet Modifikationen für OOo, die sehr hilfreich sind (und die Optik verbessern :-)). Unter anderem die Anbindung von OOo an Cups klappt damit besser. Siehe Ximian Homepage. 3. Unter KDE empfiehlt sich der OOo Quickstarter. Der ist in der Taskleiste verfügbar und lädt OOo nach der Anmeldung zu Teilen in den Speicher. Öffnet man dann beispielsweise den Writer, dann dauert das auf meinem System etwa den Bruchteil einer Sekunde. Im Prinzip steht die Anwendung sofort. :-) Das Programm gibt es hier: http://segfaultskde.berlios.de/index.php?content=oooqs Viel Erfolg, Tobias W.

Hallo Thierry, Am Fr, den 13.02.2004 schrieb Thierry de Coulon um 16:16:

Hallo Tobias

On Friday 13 February 2004 11:11, Tobias Weisserth wrote:

...

...

Welche Version? OOo ist zwar nie schnell beim Start, aber bei mir (Doppel Athlon MP 1800+) dauerte es genau 5 Sekunden (wobei ich OOo schnon einmal gestartet hatte heute Morgen, was glaube ich die Sache verbessert, beim ersten Start muss das Programm wohl irgendwas wichtiges tun...)

Vergleich zu meinem System:

Athlon 1400 mit 1,25GB RAM: OpenOffice 1.1.0 mit den Ximian Patches startet beim ersten Mal in unter 10 Sekunden und jedes weitere Mal in unter 5 Sekunden. Gut zu wissen, dass sich ein Dualsystem fÃŒr OOo nicht wirklich lohnt ;-)

Soweit mir bekannt ist OOo nicht an Multiprozessoren angepasst (kommt ja aus der Windows-OS/2 Welt).

Ich weiß nicht, ob es eine spezielle Optimierung für SMP bei OOo gibt. Aber die Begründung ist definitiv unsinnig, weil auch Windows NT/2000 aufwärts mit mehreren CPUs jonglieren können. Im Übrigen sind die Windows Wurzeln von Star Office nie exklusiv gewesen. Ich habe hier die Version 3.1 von Star Office sowohl für Windows 3.1 als auch für OS2/v2. Bei Star Division hat man sehr früh auf Portierbarkeit geachtet.

Die Vorteile von SMP sieht man nicht in der Geschwindigkeit (meistens), sondern im Multitasking.

Das trifft vielleicht auf 08/15 Software zu, die man beispielsweise aus dem i386 Zweig einer Distribution fertig kompiliert installiert. Dann verschenkt man unnötig die Vorteile eines Dual-Systems oder den besonderen Befehlssätzen seiner fortgeschrittenen CPU Architektur. Wenn man dann noch UDMA ausgeschaltet hat und hdparm ein Fremdwort ist, dann ist klar, dass der IDE Bus eine hohe CPU Last erzeugt. Aber das löst man nicht durch eine zweite CPU sondern elegant durch die richtige Konfiguration. Jede Anwendung, die mit Multi-Threading arbeitet, kann theoretisch von mehreren CPUs profitieren. Da OOo beim Starten sicher wesentlich mehr als nur einen Thread benutzt, der alle anfallenden Operationen hintereinander listet, wird OOo in gewissem Maße auch von einem Mehrprozessorsystem profitieren, wenn man es dafür übersetzt hat und der Scheduler mit mehreren CPUs umgehen kann. Das trifft übrigens auf alle Anwendungen zu. Die Vorteile beim Multitasking liegen ja eben in der Eigenschaft, dass ein Prozess mehrere Threads haben kann und die alle auf verschiedene Zeitscheiben von CPUs verteilt werden können. Einen Vorteil beim Kontextwechsel gibt es sicherlich auch, aber dafür lohnt sich ein SMP System kaum.

Beispiel: auf alle Einzelpozessor Geräte kommt Linux fast zu einem Stillstand, wenn Linux mit der (IDE) Festplatte beschäftigt ist.

Falsch. Das war vielleicht mal so in Zeiten vor Ultra ATA so. Mit einem anständigen Controller (heute auf jedem neuerem Board) und einer Ultra ATA Platte am IDE Bus gibt es auch auf langsameren Systemen kaum noch extensive CPU Belastungen durch IDE Bus Operationen. Ich habe eine Ultra-DMA/133 Platte an einem DMA/100er Controller und habe mit meinem Athlon 1400 keine Einschränkungen im Betrieb mit IDE. Das trifft auch auf Operationen mit optischen Laufwerken zu. Was Du da anführst, ist ein moderner Mythos.

Bei zwei Prozessoren bleibt ein ordentliches Arbeiten möglich.

Das hat erstmal nichts mit der Anzahl CPUs zu tun. Schau mal hier: http://www.seagate.com/support/kb/disc/ultra_ata_faq.html

Gerne würde ich aber erfahren, ob das "Multithreading" in den neusten Intel Prozessoren gleich wirkt oder nicht.

Wie gesagt. Die CPU spielt bei Belastung durch IDE Operationen eine untergeordnete Rolle. Entscheidend ist, in welchem Modus der IDE Bus läuft, weil das eben die Belastung der CPU definiert. Das Problem mit zwei CPUs zu erschlagen, macht den IDE Bus nicht verträglicher, lediglich die relative Auswirkung auf zwei CPUs ist kleiner. Der Grund warum ich mein System neben Dein System gestellt habe ist, weil ich etwas überrascht war, dass ein modernes Dual-Athlon System mit vergleichbarem Arbeitsspeicher und schnellerer Bus-Architektur nicht wesentlich schneller beim Laden des OOo Mammuts ist. Um ehrlich zu sein, hätte ich mir von Deinem System wesentlich mehr erwartet. Deshalb die Aussage, dass ich relativ zufrieden mit meinem Athlon 1400 bin ;-) Gruß, Tobias