VERSIONS: All (?) - written for Paradox 5
SUBJECT: CompileInformation() - SymbolTable Size
BY: MARK PAUKER
Date: 15 February 1996
I've noticed a fair bit of traffic lately about symbol table size, so I thought I'd share the somewhat surprising results of an analysis I recently
completed on the subject.
I have concluded that explicitly naming a lot of objects on the form (which most of us have traditionally pointed to as one of the main culprits
in eating up symbol table space) is not really too big a contributor to the problem. In my tests, naming objects used about 10 bytes of symbol table
space per object (on average), which is only likely to cause a problem when several hundred objects are involved. I still don't recommend naming
objects without a reason, but I don't believe that this is the root of most people's symbol table problems.
Although the results about naming objects come as a pleasant surprise, there was an unexpected down-side as well. It seems that every
method you place code in has an overhead averaging between 150 and 250 bytes. This is true even if all you do is place a comment in the method.
Thus a single object that has code in several built-ins can eat up 1K-2K of symbol table space before any of the symbols in the code are even looked
at.
As an example, consider a fancy button composed of bitmaps. That object probably has code in its mouseDown, mouseUp, mouseEnter, and
mouseExit. It may also have code in its open (for initialization), and in its mouseClick (or pushButton). Thus before we account for the code itself,
this object has used over 1K of symbol table space. With the code, it consumes approximately 2K. This is roughly 3% of your total symbol table
allocation being used by a single object, before that object has been given any code to do any real work.
So how do you use this knowledge if you're running into symbol table problems? First, you can replace items that are using a lot of symbol
table space. For example, the special "bitmap button" mentioned above can be replaced by a standard button with a bitmap contained inside of it.
This will eliminate the flashy animation when the button is pressed, but will also reduce the symbol table size by almost 2K per button.
Next, you may be able to centralize the trapping of events. For example, rather than trapping for actions (such as DataLookup) within each
field of a tableFrame, you could trap for them at the record level (looking at the target to determine where the action came from). If the event in
question doesn't bubble, you can trap it centrally in the form's preFilter. (This will have a slight performance hit and may tend to make your code
a bit less manageable, but it can dramatically reduce symbol table usage by cutting down on the number of methods you place code in.)
Please recognize that I'm not suggesting that anyone change their coding style-- only that if you are running out of symbol table space, there
are ways to reduce its size that you may not have considered. Further, the traditional approaches of un-naming objects and moving code to
libraries aren't necessarily going to do too much for you. (Moving code to a library will almost certainly reduce your code size, but may not reduce
your symbol table size appreciably. In fact, it could end up increasing its size if you aren't able to move many variables to the library.)
From : Mike Prestwood
Your analysis is good and appreciated. Here is a little bit of input from me, my conclusions (very similar to yours), and one question.
In my tests, naming objects used about 10 bytes of symbol tablespace per object (on average)
One of the R&D folks once told me that the name of the object and a four byte address are stored in the symbol table. Therefore, an object
named "Last_Name" would take up 13 bytes (9 for the name and the four byte address).
I still don't recommend naming objects without a reason, but I don't believe that this is the root of most people's symbol table
problems.
I agree. I tested this myself and came up with the same results. All the tests I performed were in Paradox 7 For example:
- A blank form with a button on it with no code is 0.
- Added a comment to pushButton raised it to 1567 bytes.
- Added a second empty button raised it to 1705.
- Added a semi-colon to second button raised it to 2066
- I then named the button "btnTest" which should have raised it to 2077 but only raised it by 7 bytes to 2073. This means that only the name is
stored and not the address as I previously believed. Any ideas anyone?
- Added a dummy custom method with just a comment in it and the symbol table raised to 2337.
Conclusions: Variable names and object names do not have a significant impact on the symbol table, but objects, events, and methods.
Note: I tested both with Compiler Warnings and Compile with Debug checked and not checked. They did not impact the results.
Now for the question. One of my friends at Borland told me that the symbol table was raised from 64k to 128k in version 7 and another told
me the limit was eliminated. Have you heard anything definitive? Does this appear to still be a problem?
From : Mark Pauker
I then named the button "btnTest" which should have raised it to 2077 but only raised it by 7 bytes to 2073. This means that only the name
is stored and not the address as I previously believed. Any ideas anyone?
I have found it hard to generalize the amount of memory that will be used. Perhaps Paradox uses a hashing scheme that doesn't always
require the complete name to be stored. Perhaps Paradox allocates more memory than it needs when requesting memory from the central pool,
and then utilizes some of the unused space in subsequent calls. I found it easier to generalize about average usage rather than trying to figure this
out.
Now for the question. One of my friends at Borland told me that the symbol table was raised from 64k to 128k in version 7 and another
told me the limit was eliminated. Have you heard anything definitive? Does this appear to still be a problem?
I haven't done any v7 testing, but I know the limit was at least raised. My guess is that it's either 128K or 256K, because I've already seen
messages about people running out of code and/or symbol space (I don't remember which) in v7.