Needs hints to speed up the VB IDE for a large project

Hi, I have a large project  (500 files, 6 MB of code lines, 50 dll/ocx references, the EXE is 15 MB) and the IDE is very slow.

It can become stalled using 100% CPU for one or two minutes.

I think it's not just about the size of the code because it was not so long one month ago with just a couple of new files since.

This happens at the initial load when i click page down on a code window.
And again when I modify a procedure argument and go to another module and click page down, so I guess he's checking again the syntax of the whole project.
Even with no option to check the syntax or display the dropdown automatically.

I traced the filesystem access and VB6.EXE is not accessing any file when this happens.

What I've tried so far with no success:

- unloading all addins
- checking and unchecking any option I could find in the vb options form
- testing another project with no form/control/ocx
- moving all enums and types in a single class/module (I thought it could reduce dependencies if this slow down the syntax checks)
- defragmenting the drive
- removing unused code

Using VB6 SP5 on W2000, NTFS, plenty of ram available, same problem on 2 different machines

I'm especially looking for hints from people who had a similar problem and found a way to improve the ide speed (something else than splitting the code into several projects !)
LVL 2
alain_tesioAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

robdogg10Commented:
I'd try the following:

1.  Clear out the TEMP folder.  Not just the system temp folder but also the user temp folder (i.e. C:\Documents and Settings\[UserName]\Local Settings\Temp and C:\Documents and Settings\[UserName]\Local Settings\Temporary Internet Files

2.  Move some classes to separate DLLs and simply reference them.  With 500 files you should be able to break up your project into a ton of separate DLLs.

3.  Uncheck unused references.  Uncheck references that are dependecies of dependencies - your main project does not need it.

4.  If all else fails, rebuild the project from scratch by adding one module at a time.

5.  There maybe an NTFS permission mess.  This means that the underlying OS code has to take extra time for each file to determine permissions.  Make sure you don't have domain users on the permission list for your files.  Actually having a domain user with access to a single file  can slow it down on a sluggish network.

Good luck!
0
DominicCroninCommented:
Just a question - why are you against splitting the programme into separate projects. This would usually be what people do. robdogg has suggested this too (point 2)

The reason I'm asking is that I'm rather hoping that your reason for not taking the 'standard' approach could be something that we can solve.

Another question is  - how clean is your registry. Every time you break compatibility you leave loads of old COM entries in the registry. Most serious coding shops use utilities to clean all that up between builds. Having lots of old registry keys will slow you down pretty much more than anything else.

Another approach to solving this is to start with a clean install of your operating system, install your development environment etc and then make an image of the disk. Every so often, check all your code in, restore the image and "get latest" of your sources. That's a lot of hard work, but it will have the desired effect. Still - investing in some registry cleanup tools is probably less painful.
0
alain_tesioAuthor Commented:
Thanks for the replies, I've tried emptying the temp folders and checking NTFS permissions, and I'll look at the registry.

About splitting the project into several DLLs it would certainly help but I'd prefer not to (this is not a problem at all except the IDE efficiency, it's harder to debug code, and I think it would be slower with calls between several dlls than having all classes in the same process, right ?)

I hoped for some less obvious "magic hints" about a known VB weakness like parsing conditional defines or a large number of fragmented files or more than 256 enums or something similar !
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

robdogg10Commented:
>>>About splitting the project into several DLLs it would certainly help but I'd prefer not to (this is not a problem at all except the IDE efficiency, it's harder to debug code, and I think it would be slower with calls between several dlls than having all classes in the same process, right ?)<<<

In one word, NO.  Once objects are in memory there is no difference in speed because everything at that point is just a memory jump.  You may get a bit of a difference (probably nothing that's perceptible to human eye) because the OS has to load more than one DLL.  

As far as debugging code, you normally debug a set of functionality.  If you have logically separated your app into logical sets of functionality (i.e. DLLs), then when debugging you will at most have 2 or 3 DLL projects loaded into the IDE.

As someone else here mentioned, you might want to clean out the registry.  There are several tools that can do that.  

One is Registry Mechanic
http://download.com.com/3000-2094-10190447.html?tag=launch

Registry Magic
http://download.com.com/redir?pid=10234738&merid=87434&mfgid=87434<ype=dl_elite_dlnow&lop=link&edId=3&siteId=4&oId=3120-2094-10234738&ontId=2094&destUrl=%2F3001-2094-10234738.html

And bunch of others.  This may really help.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DominicCroninCommented:
It probably helps to know that you can debug straight from one instance of VB to another. I often work with three instances at once in order to debug a multi-tier application from top to bottom
0
alain_tesioAuthor Commented:
Thanks for your replies, no hint (emptying the temporary folders, cleaning the registry, ntfs permissions ...) helped so I'll give points based on what I learned here, that you can load a dll and an exe in the ide
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.