If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Slow task switching
A little while ago I started a thread about the task switching delays I was
experienceing when moving between tabs or switching to a different task/starting a new one. Well, since thing the only thing that has changed is that I installed the updated version of Windows NET Framework, and now all the delays have disappeared. I never figured out what the possible cause might be, and I don't know how the upgraded NET Framework might have changed things, but I am glad the problem went away. |
Ads |
#2
|
|||
|
|||
Slow task switching
Tim wrote:
A little while ago I started a thread about the task switching delays I was experienceing when moving between tabs or switching to a different task/starting a new one. Well, since thing the only thing that has changed is that I installed the updated version of Windows NET Framework, and now all the delays have disappeared. I never figured out what the possible cause might be, and I don't know how the upgraded NET Framework might have changed things, but I am glad the problem went away. This is an example of what the tail end of a .NET security patch or new version install does. C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\ngen .exe executequeueditems That command, causes .NET assemblies to be recompiled against the current .NET library, and stored in an assembly cache. While the program loader is supposed to support "on-demand" recompilation, implying the above command "just doesn't matter", the physical evidence is, this observation is "less than true". When components of the OS don't get recompiled properly, there can be quite long delays, or various kinds of failures. The reason I know the above command, is that's how you repair WinXP network/firewall failures caused by .NET. Generally, the Vista+ OSes are a tiny bit better at doing their own NGEN runs, without you tampering with them. It should not hurt, to run that command at any time. If all assemblies are in the cache, the command should complete quickly without doing anything. As far as I know, the "version" should be the highest one installed on the PC. Check the Microsoft.NET folder hierarchy for more info. So that's the difference the installation of a .NET patch or new .NET version makes. ******* Task Manager on Win10 is an ordinary program, with no super-powers. And is ill-suited to control the OS. In fact, it's the single reason I would pay Microsoft $0 for this OS. It can't be a "software as a service" model, if there's no service. At least with WinXP, there are better odds when the system is under pressure, that I can "kill" a runaway process. I have a test case to freeze the Windows 10 OS, and it uses the OpenMP library, and large memory requests. The OS should *always* remain in control, because the scheduler is preemptive and can yank away execution from anything. All it takes, is a *decent* *responsive* Task Manager to complete the design :-( Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|