fakeraol
1. sind
Tipp 3 und
Tipp 4 inhaltlich identisch
und
2. ist der zugriff auf ram nicht mechanisch, wie der arm einer festplatte, sondern elektrisch und damit nicht durch die verteilung der daten im ram beeinflusst oder gebremst.
die vorgeschlagenen vb-scripte machen nichts anderes, als dem betriebssystem mitzuteilen, dass der vb-interpreter gerade viel ram braucht. daraufhin löscht das betriebssystem dateien, b.z. dll's, die momentan nicht verwendet werden, aber mit grosser warscheinlichkeit wieder gebraucht werden könnten.
diese müssen dann später von der festplatte neu eingelesen werden, wenn sie wieder gebraucht werden.
dieses vorgehen entspräche ungefähr dem eines busfahrers, vorsorglich 90% seiner pasagiere rauszuwerfen, weil es ja so toll ist, freie sitzplätze zu haben.
sinnvoll ist es für ihn erst, das zu tun, wenn durch die fast 100%ige auslastung seines busses beim nächsten halt die gefahr bestünde, dass durch neu hinzusteigende fahrgäste im gedränge seine bewegungsfreiheit und damit die sichere durchführung seiner tätigkeit eingeschränkt sein könnte.
"freier" arbeitsspeicher ist
ungenutzter arbeitsspeicher. wenns dem betriebssystem zu eng wird, räumt es von ganz allein ungenutzte dateien aus dem ram, um für momentane aufgaben platz zu schaffen.
diese beiden tipps sind also kontraproduktiv und damit falsch.
Hooker
Das kann man so nicht im Raum stehen lassen.
| quote: |
Original von fakeraol
1. sind Tipp 3 und Tipp 4 inhaltlich identisch
|
Die obige Aussage ist schlichtweg falsch.
| quote: |
Original von fakeraol
"freier" arbeitsspeicher ist ungenutzter arbeitsspeicher. wenns dem betriebssystem zu eng wird, räumt es von ganz allein ungenutzte dateien aus dem ram, um für momentane aufgaben platz zu schaffen. diese beiden tipps sind also kontraproduktiv und damit falsch.
|
Es mag sein, dass die Tipps, gemessen an heutigen Standards, nicht mehr einen spürbaren Erfolg bringen.
Zu der Zeit jedoch, da die angesprochenen Artikel verfasst wurden, waren 450 MHz CPU-Takt und 256 MB RAM schon das "Non-Plus-Ultra" und keineswegs selbstverständlich, auch nicht auf Windows 2000 Systemen.
Bei einer solchen Hardwareausstattung macht das Freiräumen des Arbeitsspeichers sehr wohl Sinn.
Ich hatte in meiner beruflichen Praxis mit vielen solcher "antiken" Systeme zu tun und die o.a. Tipps haben mir damals gute Dienste geleistet!
Voyager
Ich kann hier Hooker voll und ganz zustimmen.
fakeraol
| quote: |
Original von Hooker
| quote: |
Original von fakeraol
1. sind Tipp 3 und Tipp 4 inhaltlich identisch
|
Die obige Aussage ist schlichtweg falsch.
|
so?
ob im ersten Tipp von "defragmentieren" gesprochen wird (durch das ausführen des vb-scriptes werden keine dateifragmente im ram zusammengeführt, daher falsche aussage) und im zweiten von "leeren", ist irrelevant.
in beiden tips wird ein vb-script erzeugt. der name ist irrelevant.
in beiden scripten wird eine variable initialisiert, name irrelevant.
in beiden scripten wird ihr dabei eine bestimmte grösse zugewiesen.
wo ist jetzt der entscheidende unterschied?
| quote: |
Original von Hooker
Ich hatte in meiner beruflichen Praxis mit vielen solcher "antiken" Systeme zu tun und die o.a. Tipps haben mir damals gute Dienste geleistet! |
"damals" in der zeit von DOS mit den betriebssystem-aufsätzen win9x ?
die einzigen dateien, die das betriebssystem nicht so ohne weiteres im arbeitsspeicher mit neuen dateien überschreibt, sind abgestürzte programme, die vom betriebssystem nicht als solche erkannt wurden. die wird das betriebssystem aber auch nicht aus dem ram schmeissen, wenn der vb-interpreter für die variable xy platz anfordert.
die einzige mögliche auswirkung dieser vb-spielerei wäre eine systeminstabilität oder ein absturz, wenn das betriebssystem momentan gerade tatsächlich nicht so viel arbeitsspeicher zur verfügung stellen kann.
noch was:
diesen tipp können sie getrost durch einen verweis auf
http://www.ntsvcfg.de ersetzen.
klaus1
Hi,
ob das Freiräumen oder Defragmentieren des Arbeitsspeichers sinnvoll ist oder nicht, ist ein pures Rechenexempel. RAM arbeitet mit der Geschwindigkeit von ca. 2-6 Gigabyte/Sekunde. Das Anklicken von irgendwelchem Sccriptkram dauert also länger als das Überschreiben des RAM durch Windows. Viel Lärm um nichts oder auch was soll der Quatsch?
MfG
klaus1
fakeraol
eben.
windows wird bei der ausführung der vb-scriptes durch das programm "vb-interpreter" auch nichts anderes machen, als bei der ausführung jedes anderen programmes. es überschreibt als ungenutzt markierte dateien mit dem programmcode des auszuführenden programmes (oder des vb-strings) und startet dieses dann (oder lässt nach abarbeiten der einen anweisung in dem script den string als garbage (unnützen "müll") anstelle der potentiell nützlichen dateien zurück).
was den begriff "defragmentieren" angeht, der ist halt schlicht irreführend und falsch, undzwar zum ersten, weil das script keinerlei umsortierung der daten im arbeitsspeicher im sinne der zusammenführung von fragmenten bewirkt, und zum zweiten, weil es im arbeitsspeicher keine verzögerungen beim zugriff auf die dateien/"dateifragmente" gibt, wie beim mechanisch zu bewegenden lesearm der festplatte.
arbeitsspeicher fragmentiert faktisch nicht, weil der zugriff auf jede speicherstelle mit der gleichen geschwindigkeit erfolgt. dass er für die verwaltung fortlaufend (mit hexadezimalen adressen) durchnummeriert wird, bedeutet nicht, dass die einzelnen speicherstellen auch in dieser reihenfolge abgefragt werden müssten.
faktisch passiert mit diesen vb-scripten nichts anderes, als dass das betriebssystem dateien (vornehmlich dll's), die momentan von keinem programm verwendet werden (aber ohne ladevorgang von der festplatte wieder verwendet werden könnten, wenn sie gebraucht werden), mit einem berg nullen überschreibt, die den bis dahin leeren string aus dem vb-script darstellen. nun steht halt anderer müll im arbeitsspeicher, gewonnen wurde damit überhaupt nichts, im gegenteil, denn der string ist ja garnicht zur weiteren sinnvollen verwendung vorgesehen.
Genesis
Frage dazu:
ersetzen RAM-Cleaner den "Müll" im RAM teilweise durch ausgelagerte Dateien oder arbeiten diese genauso wie die Speicherzuweisung? Das Problem bei mir ist eben, dass der Rechner langsamer wird, sobald auf die Festplatte ausgelagert wird. Dies merke ich besonders bei RAM-lastigen Anwendungen und Spielen.
klaus1
Hallo Genesis,
der Fluch ist, dass man nicht genau weiß ab welchem Kriterium Windows überhaupt auslagert. Ich habe 512 MB Ram, Auslagerungsdatei 768 MB. Beim Austausch gegen 2 oder 4 oder mehr RAM würde Windows trotzdem auslagern, selbst wenn ich versuchen würde, die Auslagerungsdatei auf Null zu setzen!!
Ich glaube, das alle RAM-Cleaner und -Defragmentierer machen können was sie wollen, Windows kümmert sich einen feuchten Kehricht darum und lagert aus wie es will.
MfG
klaus1
@thehop
Hm... noch eine interessante Möglichkeit wäre,
einen grossen Teil der Pagefile.sys in eine RAM-Disk
http://de.wikipedia.org/wiki/RAM-Disk zu verlagern.
Und dann zu überprüfen ob sich damit die sogenannten Seitenfehler
http://de.wikipedia.org/wiki/Seitenfehler
sichtbar (im Task-Manger -> Prozesse -> Spalten auswählen...)
reduziert haben - was angeblich den Zugriff beschleunigt.
salü
PS: Seh grade, dass Du (auch?) DOS verwendest,
dafür gäbe es z.B.: TurboDisk
PPS: Werd ich gelegentlich mal selber ausprobieren ;)
fakeraol
| quote: |
Original von Genesis
ersetzen RAM-Cleaner den "Müll" im RAM teilweise durch ausgelagerte Dateien oder arbeiten diese genauso wie die Speicherzuweisung? |
nein, umgedreht. das betriebssystem wählt nach warscheinlichkeit der wiedernutzung momentan nicht genutzte dateien aus, die es mit den, von den sogenannten ram-"cleanern" oder ram-"defragmentierern" (da ist nix zu defragmentieren! erklärung siehe oben) angeforderten daten überschreibt.
die speicherzuweisung ist hoheitliche aufgabe des betriebssystems, genauso wie die darstellung von fenstern und darin enthaltenen bedienelementen für die oberfläche eines programmes (ausnahmen möglich).