Page 1
Page 2
Page 3
The calories
This Low Fat version didn't end up being
the end of Morris's weight loss program. While preparing
this article I revisited some of the things that the posters
in the thread had mentioned in order that I could describe
in greater detail what seemed to be in our project files
that was adding to the compiled size. It was discovered
by one member of the thread that the comments themselves
do not add to the compiled file size but the fact that they
are on a line of there own with a linefeed character did.
It was also suggested that Tab characters also added to
the size of the compiled vb file. I had noticed however
that when experimenting with Word the code files seem to
have space characters saved in place of any Tab characters
that Microsoft might be using in the IDE. So my thinking
was that, if you were to conduct a test by adding a line
with no comment or code but instead just tabbed in once
or twice, you would basically have a few spaces and a line
feed. I figured that it was probably the line feed again
that was the culprit. My little routine mentioned above
would get rid of these lines as well because it used the
Trim function before examining the line. But what about
those spaces in front of your lines of code that weave in
and out making your If statements and the like easier to
read? They wouldn't be adding to the size as well would
they? This was easy enough to test. I repeated the same
steps of recording the original compile size and running
my routine. My .vb file was now at 249,592 bytes due to
a number of modifications over the previous week. I ran
my BackUpAndStrip routine. Yes that is what I called it.
After the stripping was done, my compiled .vb file was now
235,016 bytes, again a savings of about 14,000 bytes. I
then modified my routine to trim the line of code before
writing it to the new file, half expecting to get the same
result. I frankly was rather stunned when I saw what the
actual results were. The new .vb file was down to 193,288
bytes. I checked and double-checked to make sure that I
wasn't looking at one of the many other permutations of
Morris.vb like Morris1.vb or Morrisb.vb, etc. Nope, I was
looking at the right file.
Simply stripping out the empty and commented
lines and trimming the code lines that were left reduced
my 249,592 byte file down to 193,288 bytes for a total savings
of 56,304 bytes or just over 22% of it's original size.
That is pretty substantial and I don't think I would ever
want to distribute a file for a Pocket PC device that was
one quarter full of wasted space. We VB developers have
enough hurdles to jump over to make our programs appealing
without slapping a pack of useless extra weight on their
back. Okay, so, if the first version of the utility made
a Low Fat vb file is this now a No Fat version? Unfortunately
it is not. I did more testing to confirm it but if you have
a line of code followed by some space (tabs or otherwise)
and then a comment following that space you are still packing
some extra bits. The comment is not the problem, Microsoft
seems to have taken the effort to remove or ignore everything
after the apostrophe. What still costs you is the space
between the code and the comment.
For example in the line:
x=x+1
'Increment x co-ordinate because of some reason
the leading space before the first "x"
would get removed by the stripper and the comment itself
would get removed by the compiler. The space between the
"1" and the apostrophe, however, is going to stay
and add unnecessary bloat to your .vb file. My routine does
not attempt to deal with the separation space contained
inside inline comments. It would be more work to detect
where the code stops and the comment starts but, more importantly,
it would greatly increase the possibility of mistaking apostrophes
embedded in coded strings as comments and lines of code
could be mangled in ways that would be much harder to test
for. So I kept it simple and low risk. I believe that the
gain, however, is substantial even if your lines of comments
are sparse, as I am sure you still have indentations in
front of your lines of code. Lets hope so, because if you
don't have comments and your code is flat to left margin
then there are many other articles and books that you should
be spending your time reading before you bother with this
article.
If you are experimenting with a stripper
on some of your own code (or her's <grin>), you may
notice that it often takes more than just one space or linefeed
to make the build bigger. I believe that each formatting
character is in fact adding one byte to the size of the
build, however the compiler seems to be writing the file
in complete word sizes or something along those lines. One
experimenter in the thread found that every eight linefeeds
caused an increase in the file's size by a step of eight
bytes. However only the eighth byte would actual cause the
file size to step up and the next seven seemed to use the
extra 7 bytes in the original word size that was added.
Reducing the wasted space
Regardless of the mechanics under the
covers, there are some simple things we can do to reduce
the amount of wasted space in our vb files.
First, backup and strip off the
easy stuff from your project file prior to compiling by
making your own version of a routine like I made. (The core
routines accompany this article)
Next, I recommend that if you
are going to add comments that you add them on their own
lines. This way, they are easy and safe to remove from your
code with your stripper. If you really preferred, you could
stick them right on the end of the a given code line with
only the single space the IDE forces between the last letter
of your code and the apostrophe. Personally I find that
staggering comments on the ends of code lines do not look
very appealing and can be harder to manage.
The incremental gain that might be achieved
by mucking with the spaces in the actual lines of code carries
the added risk that you might damage your code. I personally
have no interest in spending the time to test the many scenarios
that I would need to test and retest to be comfortable that
I wasn't introducing errors through code mangling. If you
are really aggressive about stripping every last waste character
out of your code you might also look at packing multiple
variable declarations on a given line but I recommend you
write code to do this with your stripper. Multiple declares
on a line make code harder to read. If eVB didn't treat
all variables as variants anyway, you would also have to
be careful to build those declares properly.
Here are the key routines I used in
my stripper utility:
Option Explicit
'Declaration section of module or form
Dim Files(2) As String
Dim BackDir As String
Dim AppPath As String
Dim StripDir As String
Public Sub Initialize()
'Run at startup or on form load
'Initialize an array of file names for all the files in
your project
'remember to size the array appropriatly
Files(1) = "C:\Data\Code\YourProject\yourfrm.ebf"
Files(2) = "C:\Data\Code\YourProject\yourmodule.bas"
'Initialize directory locations for where you want the new
files to go
BackDir = "\Backup\"
StripDir = "\striped\"
AppPath = App.Path
end sub
Previous Page
Next Page