Diskussion:SuperFetch

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Eboostr im Zusammenhang mit SuperFetch[Quelltext bearbeiten]

Ich habe Eboostr jetzt noch einmal eingefügt. Warum war es `rausgeflogen? Meines Erachtens gehört das in den Kontext, weil es genug Windows XP-Nutzer geben wird, die wissen wollen, was SuperFetch ist und ob es Alternativen gibt. Ich habe Eboostr jetzt auf 2 Rechnern je eine Woche im Einsatz und insbesondere der Start von Anwendungen ist deutlich beschleunigt. Eboostr ist auch von der ct besprochen worden. Weitere Alternativen zu SuperFetch außer Eboostr sind mir nicht bekannt, obwohl ich fleißig gegoogelt habe. --Michael Logies 16:51, 15. Jun. 2008 (CEST)[Beantworten]

Prefetch ;) Kannte schon Windows XP (aber noch nicht vorgänger)
MfG
xZise

wie sieht das ganze den in windows 7 aus? ist da auch diese oder eine änliche technik integriert? --79.226.216.135 11:57, 9. Jul. 2009 (CEST)[Beantworten]

In der Einleitung steht "SuperFetch ist eine Speichermanagementtechnik bei den Betriebssystemen Microsoft Windows Vista, Windows Server 2008 und Windows 7". Es scheint, als würde dieses SuperFetch auch bei Windows7 verwendet werden. --High Contrast (Diskussion) 10:12, 8. Apr. 2012 (CEST)[Beantworten]

Bitte Artikel nach Superfetch umbenennen, danke. (nicht signierter Beitrag von 84.44.176.76 (Diskussion | Beiträge) 06:45, 24. Jul 2009 (CEST))

Wird bei SSDs nicht benoetigt[Quelltext bearbeiten]

Wer entscheidet das? Gibt es dazu Aussagen von Microsoft? Erkennt Superfetch vielleicht sogar SSDs und agiert dementsprechend? Fragen ueber Fragen. Um es kurz zu fassen: Der Eintrag ist reine Polemik!

Auch bei SSDs kann Superfetch sinnvoll sein. Erstens ist Superfetch in der Lage, SSDs zu erkennen und sich bei Bedarf abzuschalten. Andererseits ist es auch bei SSDs nicht falsch, Programme in den RAM vorzuladen. Denn nicht jede SSD ist so schnell, das man den Unterschied nicht bemerkt oder messen kann.

Der Quatsch kann also einfach mal entfernt werden. Vielen Dank!

Sorry bitte, deine Anmerkung ist kein Stück besser bzw. bringt einem nicht wirklich weiter. Unterschreiben ist übrigens auch nicht so schwierig. Ich für meinen Teil habe auf allen meinen Systemen SF deaktiviert und damit meine Systeme eher beschleunigt. Es mag sein, dass dies auch damit zusammenhängt, wie ich meine Systeme nutze. Bevor ich SF deaktiviert habe, habe ich mir (scheinbar im Gegensatz zu einigen Anderen, die im Artikel und hier bei den Kommentaren Position beziehen) SF mal genauer unter die Lupe genommen und für mich beschlossen, dass der Mehrgewinn von SF in keinem Verhältnis zum Aufwand und Ressourcenverbrauch steht. Selbst mit Boardmitteln kann man sich sehr schön ein Bild davon machen, was SF von der Platte holt - die Logik dahinter habe ich nicht so ganz begriffen. Jedenfalls waren diejenigen Applikationen, die ich häufig nach einem Start oder im Betrieb benötige, in der Regel nicht mit dabei. Dabei hatte SF die Angewohnheit in mir nicht weiter nachvollziehbarere Art und Weise auf externen Datenträgern herumzuturnen. Das könnte ich ja noch verstehen, wenn ich z.B. Word häufig verwendet und er auf dem USB-Stick vorsorglich Word-Dokumente in den Speicher holt. Passiert aber nicht. Sinn könnte es machen, wenn SF mit niedrigerer PRio auf die Datenträger zugreifen würde - passiert aber auch nicht. Ist SF der Meinung, ich würde jetzt bald auf eine 10MB große MP3-Datei zugreifen und beginnt diese zu laden und in diesem Moment löst eines meiner Programme einen Speicherzugriff aus, dann hätte ich schon erwartet, das SF sein Laden sofort abbricht. Passiert aber ebenfalls nicht. Bei einem (sorry für den Begriff) gemütilich genutzen Hausfrauensystem mag es etwas bringen, bei intensiver genutzten Rechnern sollte es der geneigte User mal ohne SF versuchen. Dann klappt es auch mit dem Abdocken von USB-Speichern besser - weil das Medium dann eben nicht mehr in Gebrauch ist. SF wäre eine gute Idee, wenn es nicht als regulärer Prozess gleichberechtigt neben anderen laufen würde. Das zwar Prozesse priorisiert werden können, nicht aber Laufwerkszugriffe, ist ein grundsätzlicher Archtekturfehler von Windows. Sprich: Erfordert ein höher priosierter Prozess einen Datenzugriff, sollte normalerweise der des niedriger priorisierten abgebrochen werden und erst dann fortgesetzt werden, wenn dieser wieder an der Reihe ist. Fehlende Priorisierung beim Datenzugriff, fehlender Readout und fehlende Selbstdefragmentierung sind die drei Themenfelder, die bei Windows dazu führen, dass die Performance eines Windows-Systems so extrem von der Plattenleistung abhängig ist. Superfetch - so habe ich das Gefühl - war/ist ein Versuch das etwas zu kaschieren. 2003:CB:A72D:B201:F8D2:1634:368B:8D18 23:24, 4. Jul. 2019 (CEST)[Beantworten]

"Das ist kein Nachteil, da der Speicher direkt wieder vom Betriebssystem freigegeben wird"[Quelltext bearbeiten]

Das ist Unsinn. Das Problem ist ja nicht der schnelle Speicher sondern das langsamere Medium, was durch diese Möchtegernoptimierung dauergestresst wird. Wenn man es ernsthaft nutzen möchte, während Superfetch gerade damit herumspielt, wird man definitiv ausgebremst z.B. weil sich der Lesekopf an eine ganz andere Stelle bewegen muss. Der Effekt mag ja gering sein, ist aber trotzdem vorhanden. Mal ganz davon abgesehen, dass ständiges Lesen mechanische Laufwerke & Medien auch verschleißt. --93.227.7.235 09:52, 17. Mai 2018 (CEST)[Beantworten]