Why VB compiler is allways running !?
I′m sorry, i just don′t want to be rude.
I have a few simple questions !!!
1o Microsoft want to KILL VB !?
2o if not, so why the stupid compiler start compiling a every line i wrote.
3a Why this experiencing is not lived by the C# compiler !! perhaps the C# team made very good job !!!
4o The performace patched release by you guys, work but the problem is not solved, the IDE continues flinking, the compiler is allways running, the bigger projects continues to be slow to work on them.....
Sorry, but í′m working with VB.NET for a quite long time ( since VB.NET 2002 and 8 hours day) , and i′m doing a very large application since them and for the last 6 to 8 months i was experiencing something that i never imagine,
slow preformance = low productivity.
thks
JSB
[829 byte] By [
Jo?oS.B.] at [2007-12-24]
Did you ever add a class to your project and start using it on a form. When you start using it you get intellisense. That is because the background complier is running. In c# you will have to build the app to get intellisense on a class you created. Check out Paul Vicks Blog on Background Compilation for more info.
When I got my VB hotfix a microsoft Rep contacted me to make sure everything was working. Please send feed back to the rep so the issue can be fixed
In order to speed up your performance, consider adding more memory on your computer. If you have low memory, your hard disk with trash the swap file during the compilation. If you have more memory, it won't need to swap out and the perceived performance should improve. It will also reduce the amount of race conditions that the compiler will need to contend with. When I bumped my box to 1 gig ram from 512 I saw a dramatic increase in performance. Note, I typically sit at 800+ meg in use with 200+ in devenv so 512 was definately straining it.
The background compiler is what separates VB from C# in terms of productivity. With C#, you need to recompile to see both new classes/methods and also a number of syntax and other compiler errors. VB shows them more immediately as Ken suggested.
Jim Wooley
http://devauthority.com/blogs/jwooley
really guys..
try working on a very big project, and off course let your computers away ( Xeons with 4 processors and 10 tons of memory and so on ) and buy a normal computer or a laptop, and start working on them, you will experiencing a very real cenario.
Believe in me slow compiler = low productivity.
I agree with you a slow complier means low productivity. Please supply Microsoft with some feedback so that they can fix the problem.
perhaps the recent QFE would help your performance issues.
Also, as someone who switches between vb.net and c# I find the lack of background compilation in c# painful, and rely on 3rd party tools such as resharper (which essentially runs as a background compiler) to make c# as equivalent a RAD environment as vb.net is out of the box.
Cathal
Hi, Jo?o,
I'm sorry to hear about your performance problems; we take such things very seriously and want to make sure that we have all of them covered.
Ken, Jim, and Cathal have all covered this somewhat, but just to summarize the answers to your questions:
(1) We are not trying to kill VB (which is good, as I like my job 
)
(2) All of our UI features rely on compiled symbols for their richness, hence the need for a background compiler. See that entry that Ken mentioned above, or see my article at http://msdn.microsoft.com/msdnmag/issues/05/06/AdvancedBasics/default.aspx, for more details.
(3) C# lacks a background compiler, but that also means that they lack a lot of the in-line feedback VB provides. If we do our job right, then the background compiler operations shouldn't be noticeable (ideally). We've had some issues in larger-scale projects (particularly on lower-memory machines) but have taken steps to address them as they are reported.
(4) If the recent QFE is not working for you, we'd definitely like to hear about it. We have a number of large project scenarios we test (and are adding more all the time), and we also test fixes on customer machines with their consent, but due to the complexity of large projects we can never be sure of touching all of the possible combinations which are interesting performance-wise. If you could add your information at http://connect.microsoft.com/site/sitehome.aspx?SiteID=210, we'd be able to follow up and see exactly why it's slowing down on your machine (we have some pretty strong tools for this now).
Thanks,
--Matt--*
This answer seems to refuse to acknoledge the core problem. VB in 2005 is miserably slow, and you guys would rather think you made good decisions with background complie rather than admit you messed up big time. There is no computer on the market that can successfully support the back ground compile feature.
In short, we need the ability to turn the mip waster off.
Start listening to the customer.
Wade
This is a very important issue for me and my colleagues. We all have 2.4GHz CPUs, 2GB RAM, Windows XP SP2 and VS2005 with hotfixes KB917452, KB920282 and KB920805 installed. Whenever we edit even one character of source code in a line, the editor hangs for at 30 seconds.
Although we routinely edit large solutions, I can reproduce the issue even in a one-project one-class solution with less than 50 lines of code. That indicates to me something has gone wrong. Are we perhaps missing a performance hotfix?
If we could at least have a button that toggled the compiler on and off while editing, that would make the IDE useable again.
Regards
Chris
Chris,
Out of curiousity, do you have the datasources window open while editing? If so, try closing it. I have found a race issue with it that causes the behavior you are seeing. It might be helpful if you can post that 50 line code sample that can replicate the issue so that the team can see the specific case you are identifying.
Jim Wooley
http://devauthority.com/blogs/jwooley
 WadeColorado wrote: |
VB in 2005 is miserably slow, and you guys would rather think you made good decisions with background complie rather than admit you messed up big time. There is no computer on the market that can successfully support the back ground compile feature. |
|
That's odd. I've got an Athlon XP 3000+ with 1 GB of DDR RAM, which isn't pitiful but is hardly a beast of a machine. Nevertheless, I have no trouble working in VB while simultaneously playing music in WinAmp, surfing 2 or 3 websites at a time, and chatting on AIM. I'm sorry the background-compile feature hurts your productivity, but that doesn't mean it's a horrible decision or that it should be eliminated. For some of us, myself included, it works great and makes coding quicker and easier.
Is your project a Windows Forms Project? If so try installing the following hotfix too: KB 916209
Hope this helps, Abel.
First of all you are not going crasy and you are not alone..
1. VS 2005 VB.NET compiler is simply ***!! it is not even beta code..
It simply cannot be used for any significant VB.NET project ( ours is ~ 10,000 files of asp code).
Isimply regrest the day I moved from vs 2003 VB.NET
2. There are many many threads of simular experiences to you long before the release of vs 2005, so MS knew all about the problems before release!!
3. The machine/memory does NOT fix the broken compiler.
4. When will it be fixed.. based on almost 12 months since the relase and still NO fix in site, I suspect NEVER is the answer.
All MSoft people seem to want to do is work on the next beking code change rather than produce a working compiler...
The only hope is a) stick with vs 2003 VB.NET and wait b) for VS 2008..the real vs 2005 SP1..
PS: The beta vs 2005 SP1 is an even bigger dog than the release, see the many threads on SP1 and the 2 to 20hr upgrade..
| WadeColorado wrote: |
| There is no computer on the market that can successfully support the back ground compile feature. |
|
The background compilier works great on visual basic 1-6 , vb.net 2002, and vb.net 2003.
