Microsoft's latest versions of the IDE have been incredibly slow. You can blame they dotNet for that, because that's what it's made in.
Had it been made in C or C++, you can bet it would be much, much faster.
I guess it's because I upgraded my comp to a quad core system that I don't notice it, but even before on my last setup 2008 pro didn't run slow at all.
Oh, it's alright if you have a dual core or quad-core and a lot of memory, but if you don't...
It's literally crawls.
And it still does sometimes, when you do something specific, such as searching for declaration or definition, while other IDEs such as C::B does it instantly.
true, I use Visual Studio only for C#, and C++ in C::B. Though nothing is as heavy as Netbeans.
Not that I doubt your fact that it is incredibly slow, but I wonder how you have determined that it's caused by dotNet. Did you actually profile the code, or did you just come to that conclusion by deduction "It is slow, the old version was not slow, so thus it must be dotNet because that has changed" [By the way, I thought older msdev.exe were also dotNet - but I can't verify at present].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I too have never proved it. And I go "ugggh" when I have to use dotNet programs and alike. Call it prejudice if you will.
But I'd love to be proven wrong -- *cough* Elysia
By the way, I'm not saying Elysia IS wrong - I'm just asking if there is concrete evidence or just speculation behind that statement.
I have previous experience of WinDBG being slow [as in using 100% of one cpu on a decent machine] when you print a lot of output to the debug screen. I came as far in analyzing it that I found one loop that used about 80% of the CPU time, and it was spending that time traversing a linked list in another MS library used by (amongst other products) WinDBG - of course, WinDBG is not written in dotNet (at least it wasn't then).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I can't say I have proof, so call it speculation.
All I do know is that 2003 (or 2002?) worked fine on a computer, but when I tried 2005, it slowed to a crawl.
And indeed, I remember 2005 being slow on my computer when I had single core, but on my dual core, it works pretty fast.
And I do know it's built on dotNet, as well (check with Process Explorer, for example).
Those are my only evidence.
Only thing that I know of written in .Net in VS C++ Express Editions is the GUI. In a PIII 1Ghz wih 512Mb RAM C++ 2005 Express Edition ran satisfactorily. Once loaded (which did take some time after reboot), i could load projects and files, edit code and build projects just as I would normally with any other IDE. Not faster, not slower, with the exception of the compiler which always seemed to me faster than MinGW. Only thing that used to bother me was the incredibly slow help system.
I haven't tried 2008 yet. So, no idea. But I don't think .Net has anything to do with the fact it is slow (if it indeed is). 2005 Express suffered from similar problems before SP1.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
It's not severe speed issues or anything. It's just slow here and there, but once I get into my project it starts to speed up. It's big things like opening up large projects, opening up the settings dialog and selecting a tab such as the Fonts and Colors (?) and using the form designer (I was just looking at it, I know how anti CLR C++ you people are). And it just feels big if you know what I mean. But it could just be my computer since Windows has been going really slow lately and crashing, I think it's time for a clean up.