Warum kann der Schwebeflug über der Windows-Taskleiste meine Anwendungen freigeben?

319
Andrew Cheong

Ich kaufte ein Thinkpad 570, das RAM auf 4 GB herabsetzte, und von SSD auf HDD, sodass ich meine eigenen Komponenten günstiger kaufen konnte, als Lenovo für Upgrades in Rechnung stellte.

Während ich auf Teile wartete, fing ich trotzdem an, den Laptop zu benutzen. Es ist erwartungsgemäß schrecklich.

Allein durch Chrome wird der Arbeitsspeicher leicht ausgereizt, und es friert alle paar Minuten einige Sekunden lang ein. Wenn ich YouTube- oder Twitch-Registerkarten geöffnet habe, dann buchstäblich alle 30 Sekunden.

Ich gehe davon aus, dass dies auf Paging zurückzuführen ist. Ich bemerkte jedoch, dass es beim Einfrieren der Maus, sobald ich die Maus über die Windows 10-Taskleiste bewege, immer in dem Moment wieder freigibt, in dem die Maus darüber schwebt. Das ist mir auch bei anderen Anwendungen aufgefallen, zB ExpressVPN, Simplenote. Und es ist nicht nur "Zufall" oder scheinbar so, als ob der Trick funktioniert. In den letzten Tagen habe ich es mir zur Gewohnheit gemacht, den Mauszeiger immer dann in die Taskleiste zu bewegen, wenn eine Anwendung einfriert, weil die Anwendung definitiv aufwacht, wenn die Maus in Kontakt tritt die Taskleiste, 100% von vielen, vielen Versuchen.

Ich bin nur neugierig, ob es jemanden gibt, der sich mit O / S-Design, Windows 10, Paging usw. auskennt. Warum würde ich die Anwendung plötzlich mit der Maus über der Taskleiste bewegen?

1

1 Antwort auf die Frage

0
Andrew Cheong

I upgraded to 32 GB of RAM, and no longer have this issue, though I'm still on a 7200 RPM HDD. This supports my theory that it was a paging issue.

I also noticed before the upgrade that my cursor specifically had to be over one of the tasks on the taskbar, for that task to unfreeze. I don't know how to prove this, but my theory is that hovering the mouse over a task initiates a thread to generate a window preview, which in turn places that task at a higher priority slot in the scheduler. Without this scheduler boost, it was stuck in a lower-priority queue due to its having been paged. (Though, I would imagine paging schedulers use some form of MRU prioritization algorithm, so I don't know why the task was deprioritized so much...)

Verwandte Probleme