So...what's .NET doing, exactly?
-
After installing an update to VS, I mean. Right now, I just updated to 17.5.4 (released earlier this week) from the previous 17.5.3. Without fail, every time Visual Studio gets updated (I'm on 2022, but saw the same with previous versions), Task Manager shows many, many instances of mscorsvw.exe launching and running one after another--sequentially, not in parallel--for mere seconds each (< 2 seconds on average). It's actually a bit difficult to visualize with Task Manager as you might not even spot much going on, except that on each refresh the process (mscorsvw.exe) has a new PID and args, which means an instance has shut down, and a brand new one has started. I actually wrote a utility a while ago to log all process launches and shut downs, with full command-line args, etc, and right now - about an hour after the VS update process itself has completed and exited - I'm looking at over 800 instances of that process that have launched/closed (and still counting), each with params such as:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe -StartupEvent d80 -InterruptEvent 0 -NGENProcess d04 -Pipe d00 -Comment ""NGen Worker Process""
I realize this is one of those things that ultimately are "normal" and entirely to be expected (don't worry your pretty little head, after all, just let MS do its thing), but I'm just curious, if nothing else but for the fact that it seems excessive. I don't recall ever seeing any article or blog entry discussing what's going on during that phase. [Unrelated: My utility demonstrates Win10 is consistently launching/closing roughly 10x more processes on their own, 24/7, than any predecessor ever did in the same amount of time. For all its progress in power-saving claims, this seems counterproductive. Again, why should anyone care? I'm not sure. I'm just sharing the observation...]
I always thought a question like this is a newbish thing to ask but it’s not. To figure it out you have to know something about what Windows does internally in the first place
-
[For argument's sake] But the VS binaries I downloaded can only run on x86 anyway. Why are the binaries I downloaded *not* already precompiled as native x86, and save *everyone* that extra step?
There are ARM versions of Visual Studio. And even on the Intel x86 architecture, there are newer and faster instructions to take advantage of. Or you prefer to be like C++; their generated instructions stick to archaic and minimum 80x686 instructions.
-
After installing an update to VS, I mean. Right now, I just updated to 17.5.4 (released earlier this week) from the previous 17.5.3. Without fail, every time Visual Studio gets updated (I'm on 2022, but saw the same with previous versions), Task Manager shows many, many instances of mscorsvw.exe launching and running one after another--sequentially, not in parallel--for mere seconds each (< 2 seconds on average). It's actually a bit difficult to visualize with Task Manager as you might not even spot much going on, except that on each refresh the process (mscorsvw.exe) has a new PID and args, which means an instance has shut down, and a brand new one has started. I actually wrote a utility a while ago to log all process launches and shut downs, with full command-line args, etc, and right now - about an hour after the VS update process itself has completed and exited - I'm looking at over 800 instances of that process that have launched/closed (and still counting), each with params such as:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe -StartupEvent d80 -InterruptEvent 0 -NGENProcess d04 -Pipe d00 -Comment ""NGen Worker Process""
I realize this is one of those things that ultimately are "normal" and entirely to be expected (don't worry your pretty little head, after all, just let MS do its thing), but I'm just curious, if nothing else but for the fact that it seems excessive. I don't recall ever seeing any article or blog entry discussing what's going on during that phase. [Unrelated: My utility demonstrates Win10 is consistently launching/closing roughly 10x more processes on their own, 24/7, than any predecessor ever did in the same amount of time. For all its progress in power-saving claims, this seems counterproductive. Again, why should anyone care? I'm not sure. I'm just sharing the observation...]
dandy72 wrote:
I'm looking at over 800 instances of that process
Not sure if this is a bug or not, but either way VS is bloatware now. It should not take 40GB+ or whatever it is for an IDE.
Jeremy Falcon
-
*lol* before a decade (and more) one complained about the dll hell. Nowadays I have the strange feeling it became much worst... ... VS which one now? ... .NET x/y/z/core this and that, which one now? ... Nuget I changed here and there :wtf:
The end of DLL hell was a sales pitch. Different names these days. Same principle.
Jeremy Falcon
-
[For argument's sake] But the VS binaries I downloaded can only run on x86 anyway. Why are the binaries I downloaded *not* already precompiled as native x86, and save *everyone* that extra step?
anything vectorizable would have a bunch of versions depending on how new your CPU is. Older CPUs also need extra defensive programming around speculative execution exploits. In theory they still could have precompiled binaries, but it's a lot more than just: x86, x64, or ARM?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
-
There are ARM versions of Visual Studio. And even on the Intel x86 architecture, there are newer and faster instructions to take advantage of. Or you prefer to be like C++; their generated instructions stick to archaic and minimum 80x686 instructions.
-
After installing an update to VS, I mean. Right now, I just updated to 17.5.4 (released earlier this week) from the previous 17.5.3. Without fail, every time Visual Studio gets updated (I'm on 2022, but saw the same with previous versions), Task Manager shows many, many instances of mscorsvw.exe launching and running one after another--sequentially, not in parallel--for mere seconds each (< 2 seconds on average). It's actually a bit difficult to visualize with Task Manager as you might not even spot much going on, except that on each refresh the process (mscorsvw.exe) has a new PID and args, which means an instance has shut down, and a brand new one has started. I actually wrote a utility a while ago to log all process launches and shut downs, with full command-line args, etc, and right now - about an hour after the VS update process itself has completed and exited - I'm looking at over 800 instances of that process that have launched/closed (and still counting), each with params such as:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe -StartupEvent d80 -InterruptEvent 0 -NGENProcess d04 -Pipe d00 -Comment ""NGen Worker Process""
I realize this is one of those things that ultimately are "normal" and entirely to be expected (don't worry your pretty little head, after all, just let MS do its thing), but I'm just curious, if nothing else but for the fact that it seems excessive. I don't recall ever seeing any article or blog entry discussing what's going on during that phase. [Unrelated: My utility demonstrates Win10 is consistently launching/closing roughly 10x more processes on their own, 24/7, than any predecessor ever did in the same amount of time. For all its progress in power-saving claims, this seems counterproductive. Again, why should anyone care? I'm not sure. I'm just sharing the observation...]
-
[For argument's sake] But the VS binaries I downloaded can only run on x86 anyway. Why are the binaries I downloaded *not* already precompiled as native x86, and save *everyone* that extra step?
-
[For argument's sake] But the VS binaries I downloaded can only run on x86 anyway. Why are the binaries I downloaded *not* already precompiled as native x86, and save *everyone* that extra step?
The code is compiled to IL, just not JIT-compiled to machine code. NGEN does this ahead of time (AoT) to improve startup performance at the expense of disk space, assuming disk reads are much quicker than JIT compilation. This also saves time and bandwidth transferring only the IL from Microsoft.
-
The code is compiled to IL, just not JIT-compiled to machine code. NGEN does this ahead of time (AoT) to improve startup performance at the expense of disk space, assuming disk reads are much quicker than JIT compilation. This also saves time and bandwidth transferring only the IL from Microsoft.
In principle, it could even start executing the code up until the first point where it was dependent on something outside the image, and freeze that as a modified starting image. If the initializing code executed had no external references, it could be peeled off, once it was executed. I doubt that it is doing that, although it would be possible.