hello all,
i have Recently installed VB.Net 2005 in my computer, but it runs so slow.
my RAM is 256
does it mean it will not run fast in my computer due to low RAM? my processor is 2.4 Ghz
Printable View
hello all,
i have Recently installed VB.Net 2005 in my computer, but it runs so slow.
my RAM is 256
does it mean it will not run fast in my computer due to low RAM? my processor is 2.4 Ghz
That is a VERY VERY low amount of memory for a computer today. Most recommend a minimum of at least 4x that...
It is simple to tell if that is the problem. Just use Performance Monitor to watch what your system is doiing...
what is Performance moniter ? and where i can find it in my computer
What kind of memory your computer uses? (or what model of motherboard? - if don't know how to answer, download CpuZ from www.cpuid.com -).Quote:
Originally Posted by chunks
1 Gb of ram DDR2 800 cost around 30 U$S. Consider upgrading before it gets unavailable.
_
:confused:Did you ever hear of "Control Panel"????? :rolleyes:Quote:
Originally Posted by chunks
VS 2005 is slow period. I am running it on a AMD X2 4400+ Sata II HD 2gb PC6400 DDR2 and it is still slow. Takes a long time to load and is slow switching between design view and code view and often generates an error when switching between the two which causes it to have to redraw everything making it even slower.
This is by far my biggest gripe about VS 2003+
I originally installed 2003 on a P4 2.8 ghz with 512m and it was slow. I moved it to a AMD 64 3500+ with 1 gig and Sata drive and still slow now on X2 4400 with 2 gigs and even faster drive and still slow as well as the error mentioned above in both VS 2003 and 2005 on all three machines.
Yes, is slow. Also having 256 Mb makes it a lot, lot, lot slower.Quote:
Originally Posted by WillAtwell
The reason is, that windows use hard disk to swap memory, even when lots of memory are free. That makes the hard disk the main bottleneck.
It may improve with a RAID 0 of SSD disks. (I hope)
I have 2 Gb on my house, and after windows XP boot, 400
Mb of RAM are occupied.
Can someone plase quantify "slow" [10 million years is fast to an evolutionist, 0.0000000001 seconds is fast to a nuclear physicist]
My current solution is of moderate size with 34 projects consisting of 3000+ files. All times based on 10x average...
Visual Studio Load Time: 11 seconds
Solution Load Time: 28 seconds
"Null" Build: 8 seconds
"Full" Build: 3 minutes
"Designer"/"Code" toggle: (approx) 0.7 seconds.
To me that is very reasonable performance.. Dell Latitude D630 2GB....
I are working on a PC with 512 Mb and HT.Quote:
Originally Posted by TheCPUWizard
The project is small. VBExpress is taking 138 Mb. Firefox 90 Mb, and only 100 Mb are "free".
When I click the "start debugging" button, it takes 60 seconds to start, and at program end, it takes 10 seconds. When debugger stops at a Throw instruction on a Catch block of code, the unique way to edit the code and check it, is to stop, and run again.
Debugging is a real pain.
On my house I have an 2 gb, and a cheap raid 0, and it runs much more faster.
_
Slow in this case. I have a small project built for a mobile device. If I double click on the solution file it takes roughly 32 seconds before I see code appear on my screen for the first time. compared to vb6 where I can load a much larger project using the same method and start typing in less than 5 seconds.
Also I notice a lag everytime a property of any control is changed, like changing the name of a textbox or some such thing. I can not think of a single reason why this type of thing should not be instant on a system such as the one I am using.
The most annoying of all though is that when you make a change in the code window and go back to the design window it generates an error about 10-20% of the time and then has to redraw everthing. I think MS has a lot of garbage in there somewhere. I personally would never let a program out the door with quirks like this.
BTW after VS is loaded with my project open I am still showing 1.5 gigs of free ram so memory is not an issue.
But I bet you see, a lot of hard disk work anyway.Quote:
Originally Posted by WillAtwell
Is your case?
_
One thing I have noticed in people who report this type of problem is that they tend to not properly factor their designs so that "visual" classes only contain the information that is specific to presentation.
All too many times, I see significant amounts of code (counted by lines) in Form and Control classes that really does not belong there.
Remember the visual designer has to keep parsing these files everytime you change something. So in addition to it just being proper design to keep UI separated from Logic, it has a very practical impact too...
As well as the startup time, do you have open windows when you start? Remember all open windows must be parsed and updated. Much better if you are sure there are no open windows (especially of designer classes).
In my case there were two open windows, one designer and one code and it is not a very big project at all, It contains one additional class and 1/2 a dozen references.Quote:
Originally Posted by TheCPUWizard
As for the lag in the update of a name. My system is fast enough to rebuild every line in this project make a backup copy, zip it and save it to a flash drive in less time that it takes VS to update it in memory.
It is not poor coding, it is not a large file, it is VS doing who knows what in the background and the result is slow where there shold be no noticable lag at all.
Yes of course if you write a project and make sure all the windows are closed and only work with one window at a time and seperate all your routines into several different files it may run a little faster but development will be slower. The point is that the IDE is slow. It loads slow, it displays slow and it updates slow. It is by far the slowest designer I have ever used.
I actually haven't paid any attention to it while working in VS but I wouldn't be surprised it that were the case.Quote:
Originally Posted by Marraco
VS is usually slow when you open it for the first few times, even on fast computers. Should go away as longs as you have enough ram to handle it.