I have programmed against all versions of Windows since 3.1, so yes, I realise quite a lot about the OS. Yes, the.NET controls are mostly wrappers around the Win32 ones. That is obvious, the APIs are so similar they haven't even fixed some of the obvious problems.
I ask you (rhetorically, mainly) where would the speed difference come from? The native interop? What about if the controls were written purely in.NET? It's a JIT language -- by the time the code is running, it's been compiled to native code. The memory difference is correct, but that could certainly be minimized -- by caching the compiled stuff, mainly. There is nothing inherently inefficient about systems like.NET.
If Microsoft wanted to use.NET more, they would fix these issues, they aren't fundamental problems with the platform, they're more just implementation issues in the current version.
I know those controls (TreeView, ListView etc) aren't efficient because I've used them, and programmed using them. You can get around some of the issues, but it's pretty easy to stuff up. Native code or not -- it's irrelevant here; you're the one who thinks native code stuff is faster. Someone can program badly in any language, and the effect is pretty much the same.
I can't believe I'm engaged in this conversation, or that there seem to be so many people who think that Windows Explorer is the most complex engineering problem anyone has ever attempted. I'm giving up on this.
a) I wouldn't have access to the NTFS tables/notifications/whatever that Explorer does to get info about file changes -- so it would be at some level impossible at the moment; but ignoring that
b) computers have been capable of dealing with lists of things for quite a while. When explorer hangs because there are more than a few, it's probably actually the UI controls. The Windows list-view etc _aren't_ efficient, and Explorer's reliance on them is probably the source of the problems.
If it were inefficient, which it could well be (probably memory-wise), it would be a specific problem with a.NET implementation -- not doing escape analysis on variables (like Java 6) for example -- and it could be fixed. There's nothing wrong with the _concept_ of doing it in.NET, and if Microsoft actually tried, all the problems could be fixed up.
Performance sensitive code is the sort of code that spends 100% of its time calculating something -- like a rendering engine or something. Sitting around waiting for events to occur (whether from the user or the NTFS subsystem) does not require high-performance code. It's just a normal program. Have you noticed that the explorer doesn't sit in a tight loop using 100% of your CPU waiting for the filesystem to change? That's why those NTFS tables/notifications exist, to make the burden on the shell minimal.
Anyone could write a shell that could display 60000 things efficiently in Javascript (for example) given the right notifications from the underlying systems.
.NET code is JITed -- it _is_ native and compiled code. And it can be multithreaded. You would not notice a performance difference in a program like the shell (which isn't a performance-oriented program at all).
Slashdot Mirror
I have programmed against all versions of Windows since 3.1, so yes, I realise quite a lot about the OS. Yes, the .NET controls are mostly wrappers around the Win32 ones. That is obvious, the APIs are so similar they haven't even fixed some of the obvious problems.
I ask you (rhetorically, mainly) where would the speed difference come from? The native interop? What about if the controls were written purely in .NET? It's a JIT language -- by the time the code is running, it's been compiled to native code. The memory difference is correct, but that could certainly be minimized -- by caching the compiled stuff, mainly. There is nothing inherently inefficient about systems like .NET.
If Microsoft wanted to use .NET more, they would fix these issues, they aren't fundamental problems with the platform, they're more just implementation issues in the current version.
I know those controls (TreeView, ListView etc) aren't efficient because I've used them, and programmed using them. You can get around some of the issues, but it's pretty easy to stuff up. Native code or not -- it's irrelevant here; you're the one who thinks native code stuff is faster. Someone can program badly in any language, and the effect is pretty much the same.
I can't believe I'm engaged in this conversation, or that there seem to be so many people who think that Windows Explorer is the most complex engineering problem anyone has ever attempted. I'm giving up on this. a) I wouldn't have access to the NTFS tables/notifications/whatever that Explorer does to get info about file changes -- so it would be at some level impossible at the moment; but ignoring that b) computers have been capable of dealing with lists of things for quite a while. When explorer hangs because there are more than a few, it's probably actually the UI controls. The Windows list-view etc _aren't_ efficient, and Explorer's reliance on them is probably the source of the problems. If it were inefficient, which it could well be (probably memory-wise), it would be a specific problem with a .NET implementation -- not doing escape analysis on variables (like Java 6) for example -- and it could be fixed. There's nothing wrong with the _concept_ of doing it in .NET, and if Microsoft actually tried, all the problems could be fixed up.
Performance sensitive code is the sort of code that spends 100% of its time calculating something -- like a rendering engine or something. Sitting around waiting for events to occur (whether from the user or the NTFS subsystem) does not require high-performance code. It's just a normal program. Have you noticed that the explorer doesn't sit in a tight loop using 100% of your CPU waiting for the filesystem to change? That's why those NTFS tables/notifications exist, to make the burden on the shell minimal. Anyone could write a shell that could display 60000 things efficiently in Javascript (for example) given the right notifications from the underlying systems.
.NET code is JITed -- it _is_ native and compiled code. And it can be multithreaded. You would not notice a performance difference in a program like the shell (which isn't a performance-oriented program at all).