How can I improve performance?
Defragment your drive often!
The VisualAge for Java repository is rather large (usually over 20MB, much larger for Enterprise edition) and can fragment very quickly. By defragmenting your drive often (I defrag every day) you can speed up access to the repository.
If your disk is badly fragmented, as is usually the case with Windows NT (it doesn't come with a defragmentation tool), the disk access time increases significantly.
If you're using OS/2, this is not an issue with HPFS drives! HPFS somehow prevents or significantly reduces fragmentation.
If you're using Windows 95/98, use the defragmenter that comes with the operating system (you can access it from the "tools" page of a disk's property sheet, or from the "System Tools" submenu (somewhere off the start menu).
If you're using Windows NT, it does not come with a defragmentation tool. However, you can get a free tool at http://www.diskeeper.com - look for "Diskeeper Lite". You need to start it manually for each drive, but it's free.
Other NT defragmentation tools are available at
- http://www.diskeeper.com -
their full Diskeeper product (around $40-$45 US)
- has a "boot-time directory consolidator" that I use to put all directories in one chunk on the disk -- really helps to reduce later fragmentation
- http://www.raxco.com -
PerfectDisk (around $50)
- I like the placement algorithm on this one -- puts less-recently-used files at the start/end of the disk, more-recently-used ones at the center - this reduces disk head movement and because fragmentation usually only occurs near the center (rather than spread over the disk) reduces later defragmentation runs.
Delete unneeded things from your repository!
Smaller repositories can mean better access times for the data you're looking for. See How do I delete code from the repository? for information on cleaning out things you no longer need.
Delete unneeded things from your Workspace!
Any time you save a method, VisualAge checks dependencies in your Workspace and recompiles anything that needs recompilation. The larger the workspace, the slower this process can become. If you've got code in your workspace that you don't use (like that copy of Swing you imported to look at but aren't using in your code), do the following:
- Version the code you are no longer using.
You do this by selecting the code in the workspace (or its package or project) and choosing the "Version..." item off its pop-up menu. By versioning the code, you are locking the current incarnation of it in the repository. When you do end up needing the code, you can just bring it back in from the repository.
- Delete the code from the Workspace.
After you have versioned the code, you may delete it from the Workspace and it will still exist in the repository! Any compiles that you now do in the Workspace will no longer need to check this code for dependencies and possibly recompile it. If you need the code later, you can bring it in from the repository again. (When you bring it back in, it will be compiled against what is currently in the Workspace.)
- Keep Separate "Warehouse" Repositories!
Falling between the above two deletion schemes is what I call a "Warehouse" scheme. If you have some code that you use very rarely (such as Java samples), follow the How do I delete code from the repository? FAQ, but make sure you save the code in a separate interchange file.
For example, suppose you were developing exercise solutions for a class you are presenting. (An excellent example because that's something I do ;) You probably do a lot of work to create the exercises, then write them out to a CD or web site and don't need to use them for a while (until you find a problem or add a new exercise.)
When you're not actively using the code, you can warehouse it by exporting it to an interchange file, then deleting it from the repository. To do this:
- Version the Packages/Projects to be warehoused.
- Export them to a separate interchange file. Give it a good name so you can easily remember which one it is.
- Follow the instructions in How do I delete code from the repository? to delete the code.
- When you need it again, just import the interchange file, then add the projects into your Workspace.
Try a Different Operating System!
Some platforms use resources more efficiently than others.
Windows versus OS/2
From personal "testing" (mainly playing around to see how things are working in different environments) I've seen OS/2 consume fewer resources than Windows 95 or Windows NT. (This is on the order of 20-30MB less memory used when running the operating system and VisualAge, doing the same activities.) If you have and like OS/2, use it for running VisualAge for Java. (Note that the interchange format is compatible between the Windows and OS/2 versions of VisualAge for Java.) The OS/2 version of VisualAge for Java acts almost identically to the one in Windows. The biggest difference is that in OS/2 you drag with the right mouse button, whereas you'd use the left mouse button to drag in Windows.
Windows NT vs. Windows 95 vs. Windows 98
I have heard reports in some newsgroups that VisualAge for Java performs better on Windows 95 than on Windows NT. NT is more of a resource hog than 95, so this might make some sense. However, a bigger difference might be attributed to using a FAT partition to hold VisualAge instead of an NTFS one. (NTFS has much more to do, especially with regard to security, which slows it down.)
Windows 98 is a major resource hog, especially when it comes to managing disk cache - Windows 95 runs VisualAge much better.
Others have suggested that is you use VisualAge for Java on an NTFS partition, try compressing the repository (IBMVJavaide epositoryivj.dat) and workspace (IBMVJavaideprogramide.icx) files. I haven't tried this so I cannot comment on it.
Get More Memory!
The biggest and least expensive way to gain VisualAge performance is to add more RAM. As computers get faster, the speed of file I/O becomes more of a gating factor. If you don't have enough RAM to run the program, data must be swapped out to your disk, and that can be very slow compared to other operations on your computer.
Memory right now is incredibly cheap, and it seems that the prices keep coming down. By adding more memory, getting your system up to 128MB, you'll encounter less swapping and much improved performance.
64 MB RAM seems "ok" for VisualAge, but more can't hurt, especially if you're like me, running VisualAge for Java, a browser, a mail program, a paint program, a word processor a text editor at the same time.
Use a Fast-Access Hard Drive
If you have a SCSI hard drive on your computer, that makes a much faster home for VisualAge for Java, as well as your virtual memory swap file. (Note on NT: NT is very disk bound. It's constantly checking for something on your hard drive. If you have more than one physical hard drive (as opposed to more than one partition on a single hard drive) try to put your swap file on the hard drive that is less used (usually the one that doesn't contain the NT operating system.) This will allow your swapfile to be accessed at the same time as other files on the other drive, resulting in less head movement on the drive.
Otherwise, get the fastest access-time drive you can. VisualAge is very disk-intensive, and access-speed can make a significant difference in performance.
Get a Newer Computer!
If you are trying to run VisualAge for Java on a 33MHz 486 with 8MB RAM, forget it...
A single tool is not a good reason to buy a new computer, unless of course your entire job hinges on that tool... However, if you're finding that many of your applications are not performing well, you may want to look at buying a newer computer...
VisualAge seems to run best on a machine that's at least 200MHz or better with 128MB RAM.