Fast jeden Monat tauchen sie von neuem auf. Die dieversen "geheimen" Tuningtipps um Windows auf Formel 1 Niveau zu bringen. Fast scheint es so, als ob die Tuning Tipps einen systematischen Weg durch die verschiedenen Zeitungsredaktionen nehmen. Im Januar bei CHIP, im Februar bei PC-Welt, im März bei PC-Praxis .... und auch vor den verschiedenen Websites machen die sie nicht halt.

Aber bringen die Tipps wirklich etwas? NEIN! 90% der Tipps bringt nichts oder zumindest keinen spürbaren Nutzen. Warum halten sich aber viele offensichtlich falsche Aussagen so hartnäckig? Nun einige der Tipps brachten zu Windows 95 oder NT Zeiten tatsächlich eine Verbesserung, mittlerweile sind aber viele der Einstellungen schlicht und einfach nicht mehr vorhanden. Hinzu kommt, dass viele Zeitschriften und Webseiten sich offensichtlich nicht die Mühe machen, die Aussagen zu überprüfen.

Auch auf der WinPage waren in der Vergangenheit einige dieser Tipps enthalten, nach der Lektüre eines Artikels von Michael H. Fischer auf der Internetseite http://www.derfisch.de wurden wir aber auf dieses Problem aufmerksam und haben uns die Mühe gemacht, die Tuning-Tipps Punkt für Punkt zu überprüfen.

Soweit Möglich wurden die entsprechenden Quellen mit angegeben. Ist keine Quelle angegeben, haben wir den vermeintlichen Tipp auf einem Testsystem überprüft. Bei dem Testsystem handelt es sich um ein Rechner mit einem AMD Athlon XP 64 3200+ Prozessor mit 1 GB RAM und einer 400 GB S-ATA Festplatte (Systempartition 25 GB). Außerdem ist eine Radeon X700 XT Grafikkarte verbaut. Als Betriebssystem wird Windows XP mit SP2 verwenden (alle Patches stand 20.06.2005).

Außerdem haben wir noch ein paar andere oft zu lesende Falschaussagen zusammengetragen, die nicht in den Bereich des System-Tunings fallen.
 

Mit dem Tool BootVis läßt sich der Bootvorgang analysieren und optimieren. So zumindest war die Aussage als das Tool vor ein paar Jahren von Microsoft veröffentlicht wurde. Das ist natürlich so auch korrekt, mittlerweile ist das Tool im freien Download bei Microsoft aber nicht mehr zu bekommen, und dies aus gutem Grund. In der Praxis ließ sich nur wenig Performancesteigerung erzielen, im Gegenzug gab es aber unzählige Fälle in denen das System nach der Anwendung des Tools nicht mehr startete.
Mit RAID-Systemen (auch RAID 0 / 1) kam es ohnehin nicht klar.

Also Finger weg!
 

Nun aber weiter mit den richtig messbaren Fakten.
Der Eintrag /noguiboot in der BOOT.INI bewirkt das Unterdrücken des Bootlogos beim Startvorgang. So weit so gut. Da die einzelnen Aufgaben während des Bootvorgangs aber nicht hintereinander sondern weitestgehenst parallel ablaufen, bringt dieser Tipp in der Praxis keine merkbare Einsparung.
 

Der Prefetcher-Funktion bedieht sich MICROSOFT, um häufig verwendete Anwendungen schneller in den Speicher zu laden. Der Prefetcher arbeitet dabei wie eine Art Cache. Die gecachten Dateien legt der Prefetcher im Ordner Windows/Prefetch ab.

Wer sich um seine Anonymität sorgt, kann den Inhalt dieses Ordners gefahrlos löschen. Die Systemleistung wird dadurch allerdings nicht gesteigert. Im Gegenteil, Windows muss den Inhalt erst wieder neu anlegen, was frühestens nach 32 Startvorgängen erfolgt. Dazu muss die Leerlaufzeit ca. 5-30 Minuten nach dem Booten andauern.
Das Verzeichnis des Prefetchers läuft auch nicht voll wie es immer wieder behauptet wird, XP reorganisiert die Inhalte von sich aus und entfernt überflüssige Einträge.
Auf unserem Testsystem, welches seit einem Jahr in Betrieb ist, umfasst das Prefetcher-Verzeichnis ganze 51 Dateien mit insgesamt 3,62 MB.

Sehr ausführlich wird der Prefetcher auf der Webseite von Helmut Rohrbeck beschrieben.
 

Sehr hartnäckig hält sich das Gerücht, der QoS-Dienst (Quality of Service) würde 20% der Bandbreite reservieren, sodass diese dem Anwender beim Surfen fehlen würden. Dass dies völliger Unsinn ist, läßt sich in DIESEM Microsoft Artikel nachlesen.

Der wichtigste Auszug daraus:

Ein weiteres Gerücht ist der Tipp, das zurückspielen eines Backups der Datei WPA.DBL nach der Neuinstallation von Windows XP würde die erneute Aktivierung des Betriebssystems überflüssig machen.
Wer dies selbst schon einmal versucht hat, wird festgestellt haben, dass in diesem Tipp wenig Wahrheit steckt ...
 

Das aktivieren der Boot Time Defragmentierung bringt zur Abwechslung wirklich etwas. Dabei werden die Startdateien optimal auf dem Datenträger angeordnet und defragmentiert. Grob gesagt werden dabei also alle Bootdateien nebeneinander auf der Festplatte angeordnet, um so schneller im Zugriff zu sein.
Allerdings ist dieser vermeintliche Tipp bei Windows XP SP2 per Default schon aktiviert.

Wer es trotzdem nochmals kontrollieren möchte kann unter HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Dfrg \ BootOptimizeFunction prüfen, ob der Wert für "Enable" auf "Y" steht.
 

Eine weitere Halbwahrheit ist die pauschale Aussage, der Netzwerkkarte eine feste IP-Adresse zuzuweisen würde den Startvorgang beschleunigen. Auf einem nicht vernetzten standalone Rechner bringt dies tatsächlich einen Vorteil (sofern eine Netzwerkkarte verbaut ist). Windows versucht sonst von einem DHCP-Server eine IP-Adresse zu beziehen und wartet eben solange bis ein Timeout auftritt. Erst dann wird per APIPA eine Adresse aus dem Bereich 169.254.x.x zugeteilt.

Bei einem Rechner im Netzwerk mit DHCP oder sobald ein DSL-Router mit DHCP vorhanden ist, bringt dieser Tipp aber rein garnichts.
 

Besonders witzig ist der Tipp, man solle in der Registry unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management über die Einstellung "DisablePagingExecutive" das Auslagern des Kernels verhinden.

Bereits seit Windows NT SP3 ist dieser Eintrag nur noch aus Kompatibilitätsgründen vorhanden und wird von Windows daher nicht mehr ausgewertet, also ignoriert. Unter Windows 2000 SP4 konnte der Schlüssel sogar das Abstürzen des Betriebssystems bewirken --> siehe KB323608
 

Der Eintag "SecondLevelDataCache" unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management ist ebenfalls so ein Überbleibsel aus alten Tagen. Damit soll man den korrekten Wert für den Second-Level-Cache (L2-Cache) einstellen. Alle Rechner mit einem Prozessor mit CPU-ID ab Pentium II ignorieren diesen Schlüssel jedoch komplett, da hier der Hardware Abstraction Layer (HAL) die korrekte Größe des L2-Cache ermittelt.

Nachzulesen in DIESEM und DIESEM Microsoft Artikel. Der wichtigste Auszug daraus:

This is not related to the hardware; it is only useful for computers with direct-mapped L2 caches. Pentium II and later processors do not have direct- mapped L2 caches.
 

Ähnlich verhält es sich mit dem Tipp nicht mehr benötigte DLL-Dateien aus dem Speicher zu entfernen. Dazu war zu Windows NT Zeiten der Key "AlwaysUnload" unter HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Explorer zuständig. Seit Windows 2000 wird dieser Key jedoch nicht mehr ausgewertet, da diese Funktion ebenfalls per Default so vorhanden ist.

Nachzulesen in DIESEM Technet Artikel. Der wichtigste Auszug daraus:

Unloading the DLL
The Shell automatically unloads a DLL when its usage count is zero, but only after the DLL has not been used for a period of time. This inactive period might be unacceptably long at times, especially when a Shell extension DLL is being debugged. For operating systems prior to Windows 2000, you can shorten the inactive period by adding the following information to the registry.
 

Ebenfalls unsinnig sind Änderungen an den beiden Einträgen "LargeSystemCache" und "IOPageLockLimit" unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management. Auf einem reinen Fileserver bingen die Einstellungen einen Leistungszuwachs, da dadurch mehr Speicher für Dateisystemoperationen reserviert wird. Allerdings geht dies zu Lasten von Anwendungen. Eine normale Workstation wird also eher langsamer.

Nachzulesen in DIESEM Microsoft Artikel. Der wichtigste Auszug daraus:

Description
Determines whether the system maintains a standard size or a large size file system cache, and influences how often the system writes changed pages to disk.

Increasing the size of the file system cache generally improves server performance, but it reduces the physical memory space available to applications and services. Similarly, writing system data less frequently minimizes use of the disk subsystem, but the changed pages occupy memory that might otherwise be used by applications.