Delphi Startup Times and the Kitchen Sink
Delphi Quality Architect
|Boilerplate Registry Editing Warning: This article advocates editing your system registry (Oh No, not that!). If that is something that makes you squeamish then this article is probably not for you. If you decide to go ahead with any of the procedures I suggest below then you do so at your own risk. If something does go wrong, and it will make you feel better, you can blame me. On the other hand, I hope you will at least take comfort in the fact that I am not encouraging you to make modifications to the trigger mechanism of your shotgun collection.|
Borland Developer Studio 2006 is something I would qualify as a fairly “substantial” piece of software. It ships on four CDs and includes many extra applications in addition to the main development environment (henceforth referred to as the “IDE”). The main install program for the Architect version installs well over 20,000 files and that is not counting any of the files installed by the companion programs on the disks!
Exposing all of the features and functionality of the IDE requires a fair number of modules to be loaded by the IDE (mostly DLLs and .Net assemblies). Depending on the product version and the features installed there can easily be over 400 different modules loaded at startup time. These include things like package files that provide features for the IDE, component packages that provide components for building applications in the IDE, system files like kernel32.dll, .Net framework files, and many, many other types of modules.
As you might imagine, getting all of these modules loaded into memory and executing the initialization code associated with them takes a little time. Lucky users who happen to have blazingly fast hardware like a dual core CPU with a 10K RPM Raid 0 drive array and multiple gigabytes of RAM might not think much about the startup time of the IDE, but most users with more modest hardware probably wouldn’t mind seeing the startup time reduced a bit.
This article is intended to give you some insights into what takes the most time when you startup the IDE and to discuss ways you can tailor your configuration to improve the startup times for your own personal needs.
|Note: We are continuing to explore ways in which the IDE startup time can be further reduced from where it stands currently. The most obvious approach is typically delay loading of modules and optimizing or deferring initialization code execution. However, it is worth noting that in most cases reducing startup time though these techniques will probably introduce a delay at some point later in the IDE session while things load from disk or initialization code executes, so there is a bit of a tradeoff to modifying the product to make it load faster. I hope that there is a happy medium to be found somewhere that gives very reasonable startup times without introducing latency while accessing commonly used functionality in the IDE after startup. This article isn’t intended to focus on what we might do in the future, but rather to give you some information that will be helpful today if you are using BDS 2006.|
Digging into the new BDS.EXE –p command line switch
If you installed all of the various personalities, you will notice that you have multiple shortcuts to start the IDE in your Borland Developer Studio start menu group. One will start the IDE with all personalities installed, another will startup with just the Delphi Win32 personality installed, another just CSharp, and so on and so forth. If you look at the properties for these shortcuts, you will see that the ones that start with just a single personality contain a –p command line switch. This is a new switch introduced in Delphi 2006 to allow users to selectively load only certain IDE packages. The net effect is to reduce the IDE startup time by limiting the number of IDE packages that get loaded. It’s quite a bit quicker to load only the Delphi personality for instance than it is to load all the personalities.
In order to understand what the –p switch does you’ll want to fire up the Windows registry editor (regedit.exe) and browse to the following location:
HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages
Directly under that key, you will see a number of string entries for various IDE packages. Things like:
There are also a number of sub-keys as well (visible when you expand the Known IDE Packages key in the treeview on the left). By default, these sub-keys are CBuilder, CSharp, Delphi, DelphiDotNet, and VB. Each of these sub-keys corresponds to a particular IDE personality. If you go back and look at the shortcuts in your start menu you’ll see that each one uses one of those strings to specify loading only a specific set of packages. If you start BDS.EXE using the command line –pDelphi it is going to load all of the packages listed directly under the Known IDE Packages key as well as the ones listed in the Delphi sub-key. It won’t load any of the packages listed in the other sub-keys. When –p is not specified, the IDE will load all packages in the Known IDE Packages keys and also the packages in ALL of the sub-keys.
The real secret that I want to share with you in this article is that this selective package loading is not intrinsically tied to personalities. It’s a completely generic mechanism that can be setup anyway you want. What this means is that for those folks who enjoy tweaking things is that you now have one more tool at your disposal. You can arrange the IDE packages in whatever way suits your needs best. All you have to do is edit the sub-keys and the values they contain.
Before I go into ways you might do that I should mention a couple of other important bits of information about the –p switch. First, you can pass multiple sub-key names by separating them with a semi-colon. For instance, if you want to have a configuration that loads both the Delphi and DelphiDotNet personalities you would use –pDelphi;DelphiDotNet. The other important thing to understand is that packages that are listed directly under the Known IDE Packages key are always going to be loaded regardless of weather or not –p has been specified.
Why would I want muck around with my BDS configuration in the registry editor?
That is a good question. There are a couple of obvious situations where it might be worthwhile to pursue this. The first would be for a component development where you need to debug component designer code. To do this you will typically need to start a second instance of the IDE as a debugee under the IDE. If you are having to frequently start and shutdown the debugee IDE while doing this you can probably save a considerable amount of time if you configure it to load with only the minimal set of packages that are needed for you to test with. If you have a fairly fast machine (>=2ghz) with a reasonable amount of memory (>=768Mb) it is entirely possible to have a functional testing configuration of the IDE that will start in just a few seconds.
The other reason goes back to that “kitchen sink” thing. There is an awful lot of functionality in this product and the chances are good that you are not using all of it in every IDE session. By tweaking with the default arrangement of the IDE packages you might find that you can reduce startup times significantly by not loading things you rarely or never use. The nice thing about using the –p command line to do this is that you can gain access to that functionality when you decide you need it by simply starting up with a different command line.
Getting Started -- Backup First!
Before we get started with this, I highly recommend that you backup the entire registry under HKEY_CURRENT_USER\Software\Borland\BDS\4.0. The easiest way to do this is to navigate to that node in regedit and select the File | Export menu option and save the settings to a file on disk (I suggest naming the file something like BDS 2006 Configuration Backup.reg). This is actually a good thing to keep backed up regularly so you can easily restore your BDS configuration if needed. If you ever need to restore, you just delete the key in regedit and re-import the backup registry file. It also worth noting that if you delete that registry key (and don’t restore it) and then restart the IDE that will revert all of your configuration settings to the defaults.
|Note: Be careful not to confuse the HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE registry keys. We are only working with the HKEY_CURRENT_USER key. The values under HKEY_LOCAL_MACHINE contain the default values as well as install information and it should not be edited.|
Editing your Known IDE Packages registry key
The registry editor program that comes with Windows doesn’t support moving values around between keys so we won’t actually use it for doing editing. However, I actually find that a text editor works very well.
Start by exporting the HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages key to file on disk. If you are going to use a text editor that doesn’t support Unicode then I recommend that you change the file type in the file save dialog from “Registration Files” to “Win9x/NT4 Registration Files” before you save the file. This will create an ANSI rather than Unicode file. I actually used the code editor in the IDE itself so either format will work.
Open the exported registry file in a text editor and begin editing it. You’ll need to exercise a little care here and I suggest double-checking everything before you attempt to use the modified file. The lines in square brackets are the keys and the other lines in quotes are the values.
Let’s start by moving all of the packages that are directly under Known IDE Packages into a sub-key. This is going to allow us to easily have a virtually “zero-footprint” IDE if we need that configuration for any reason (recall that items directly under the Known IDE Packages key cannot be selectively loaded, so by moving them we will enable that to happen).
Near the top of the file, make a copy of this line:
[HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages]
and place it directly below the existing line. You’ll probably also want to add a blank line between the two to make it easier to read. Now edit the duplicated line to look like this:
[HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages\IDECore]
Note we added the string “\IDECore”. The file should now look like this at the top:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages]
[HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known IDE Packages\IDECore]
We have now moved everything that was directly under Known IDE Packages into a sub-key called IDECore.
In order to use the modified registry file we will have to re-import it into regedit. So make sure you save the file to disk and switch back to regedit. Now before we re-import the modified Known IDE Packages data we want to rename the existing registry key. That way it will become a backup of the original data. Press F2 with the Known IDE Packages key selected in the treeview and change the name to “Known IDE Packages.Save” and press enter. You can now use the File | Import menu command and select the .reg file we edited. After the file imports you will see our new Known IDE Packages key appear. If you expand it, you will see that there is an IDECore sub-key that wasn’t there before. You should also see that there are no longer any value entries directly under the Known IDE Package key. If you want to restore to the original configuration after experimenting with these instructions you would simply delete the modified Known IDE Packages registry key and then rename the Known IDE Packages.Save key back to Known IDE Packages.
To test the effects of this change we will want to open a DOS command prompt. That will allow us to test different command lines without having to create a bunch of extra menu shortcuts. Once you have a set of configurations you want to use you can go back and do that later.
At the command prompt, CD to your BDS bin directory (C:\Program Files\Borland\BDS\4.0\bin is the default).
First test will be our new “zero-footprint”. If we pass a value on the –p command line that doesn’t have a corresponding sub-key in the registry we will just end up loading nothing at this point. From the command prompt execute:
and watch as the IDE pops right up! In this configuration there are essentially no IDE packages loaded so we have pretty much zero functionality and no personalities at all. This is worthless for anything other than perhaps editing text files but it is fun to watch how quickly the IDE can be loaded! Next up, let’s try minimal Delphi personality. Shutdown and restart with this command line:
This is going to take a little longer to load but not much. Since we moved the “core” IDE packages into the IDECore sub-key and we didn’t specify it on the command line, many things did not get loaded. Next, let’s shut down and try:
Now this time the IDE churns for quite a bit longer as all of the various “core” packages load. This is exactly equivalent to the default configuration using the Borland Delphi for Microsoft Win32 shortcut that the install creates. The last thing to try would be simply:
This is going to load everything, just as it did before we made our changes. Because we didn’t specify any –p switch we ended up loading the stuff that we moved into IDECore just like it was another personality.
A Sample Configuration
Now that we have explored how to make changes to the way the IDE packages load I’ll show you an example of how you might use this technique to create configurations that are more granular. Click the link below to see a complete snapshot of a registry key that I edited:
Sample Known IDE Packages
In this sample, I used several approaches. First I broke each of the personalities up into a “core” and an “extra” key, basically I moved things that are typically used less often into the “extra” sub-key and left the more frequently used packages in the existing key. Next, I split up the packages from the IDECore sub-key we already created. In this case, I kept the critical bits in IDECore and moved most everything else into IDEExtras. Finally, I split some things out from the IDECore into a functional category. I moved all packages that have to do with doing Web development into their own sub-key and all of the ALM addins into their own key. All these changes took the configuration from five sub-keys to twelve. That provides all same functionality as the default install.
I also edited the descriptions of the various package files in that sample to have descriptions for everything. When you look at the default package descriptions quite a few just have “(Untitled)” which isn’t terribly helpful for determining what they do.
To use this configuration I might create a shortcut for BDS.EXE with a –pIDECore;Delphi switch and call that “Delphi Lite”, and probably another with –pIDECore;IDEExtras;Delphi;DelphiExtras and call that one “Delphi Full Bodied”.
This should give you some ideas of possible ways you can create your own custom Known IDE Packages configuration and a set of shortcuts to utilize it. I hope that I’ve provided enough information here for you adventurous users to begin experimenting. If you already have experience working with the registry, there is really not much to it.
Personally, I feel it is perfectly safe and reasonable for BDS users to tweak the default configuration to optimize the loading time of the IDE. However, because there are probably thousands of combinations of packages that can be configured there is certainly the possibility that you may encounter some misbehavior in the IDE with certain configurations. If you run into anything that doesn’t work right while experimenting with this, please let me know. You should be able to confirm anomalies by comparing with the default configuration. Just please be forewarned that tweaking your package configuration in this way is not an officially supported feature so there are no guarantees what your results will be.
1. The -p command line switch does not work with component packages that are installed via the “Known Packages” registry key. Unlike IDE packages, component packages can be removed and installed from within the IDE itself.
2. If you want to disable a single package in the registry, there are several different ways to do it. First, you can simply delete the entry. That is probably the least desirable way to disable something since you have to restore the deleted data somehow to undo the change. Another way is to blank out the “description” for the package. This is actually the “Data” value that is associated with a given package. A third (new in BDS 2006) way to disable packages is to edit the description and to make the first character a leading underbar. For example: “_Assembly Browser Package”. This allows you disable things without having to delete the description completely.