Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Class Library Size
- Thread starter AlastairP
- Start date
- Thread starter
- #3
Hi,
I did that and the file size returned to normal, but the next time I made a change and saved, the whole "getting larger" thing started over again
I thought this behaviour a little odd, I mean having to pack a class library. Does this mean I should do this for all of them?
You would think that part of the compiling process would do this automatically. Otherwise the .exe file would get larger and larger unexpectedly.
Perhaps I should write a PRG that packs them all prior to compiling. Like I said, seems like a step that one should not have to do....
I did that and the file size returned to normal, but the next time I made a change and saved, the whole "getting larger" thing started over again
Code:
USE C:\tfcm\libs\manageannualtests.vcx EXCLUSIVE
PACKI thought this behaviour a little odd, I mean having to pack a class library. Does this mean I should do this for all of them?
You would think that part of the compiling process would do this automatically. Otherwise the .exe file would get larger and larger unexpectedly.
Perhaps I should write a PRG that packs them all prior to compiling. Like I said, seems like a step that one should not have to do....
Dan Freeman
Programmer
I suspect something else is going on, but a ProjectHook class that packs all the vcx (and scx and mnx) files in its BeforeBuild method isn't a bad idea just on principle.
Is that VCX, after packing it, 2mb? That's a whopper!
Is that VCX, after packing it, 2mb? That's a whopper!
Olaf Doschke
Programmer
This phenomenon is not unusual, if some class of that vcx has many methods. I have this regularly with such a library being an interface to databases to many applications with many different requests and therefore code/methods all mostly put into one class.
First you need to know a VCX is nothing but a DBF table. It's the vct file, which get's larger, isn't it? That's the file containing memo data, source code and object code mostly. Code for each object is always stored in the record of that object in a code memo field. Most classes have many records, because each sub object, eg control or container, has its own record with its own memo field, but if you have eg a custom class, which by definition will have no sub objects, then that custom class only has one memo field for all it's code.
What you see happening is known as the memo bloat effect. If you change a memo (in this case by editing and adding to your code), VFP tries to fit the new value (code) into the memo block already reserved in the memo file. It can't write longer values, as that would overwrite the block of any other memo field, thus in case the new value/code doesn't fit, that block is invalidated, the pointer to the memo file in the dbf/vcx file will be changed to a new block, which is added at the end of the memo fiel. The same effect goes for classes with many records for all it's containers and controls in it, but that effect won't be as huge, a code is spread among more memos and more memo file sections, and if one of them is too small, only that code part is rewritten and the size grow is only a partial size of the class.
But let's face the corner case and say you have a class with 50 methods and a total code size of ~1 MB, you add a few lines in one method, which brings it over the memo file section reserved, about 1MB of grow happens, because the previous section of the memo (vct) file holding the old code version can't be reused and is invalidated. The new code (including all the unchanged methods) is added and takes another MB at the end of the vct. It doesn't help setting the BLOCKSIZE low or high, a low BLOCKSIZE means a rewrite more often, a high BLOCKSIZE will mean large memo file sections even for short code and both are not leading to a smaller footprint overall.
There is nothing unhealthy about this, though, it's just effecting the file size negatively, not the code speed or functionality and nothing gets broken. It also leads to large binaries (EXE/DLL) in BUILDs, so Dan's advice is a good idea.
Bye, Olaf.
First you need to know a VCX is nothing but a DBF table. It's the vct file, which get's larger, isn't it? That's the file containing memo data, source code and object code mostly. Code for each object is always stored in the record of that object in a code memo field. Most classes have many records, because each sub object, eg control or container, has its own record with its own memo field, but if you have eg a custom class, which by definition will have no sub objects, then that custom class only has one memo field for all it's code.
What you see happening is known as the memo bloat effect. If you change a memo (in this case by editing and adding to your code), VFP tries to fit the new value (code) into the memo block already reserved in the memo file. It can't write longer values, as that would overwrite the block of any other memo field, thus in case the new value/code doesn't fit, that block is invalidated, the pointer to the memo file in the dbf/vcx file will be changed to a new block, which is added at the end of the memo fiel. The same effect goes for classes with many records for all it's containers and controls in it, but that effect won't be as huge, a code is spread among more memos and more memo file sections, and if one of them is too small, only that code part is rewritten and the size grow is only a partial size of the class.
But let's face the corner case and say you have a class with 50 methods and a total code size of ~1 MB, you add a few lines in one method, which brings it over the memo file section reserved, about 1MB of grow happens, because the previous section of the memo (vct) file holding the old code version can't be reused and is invalidated. The new code (including all the unchanged methods) is added and takes another MB at the end of the vct. It doesn't help setting the BLOCKSIZE low or high, a low BLOCKSIZE means a rewrite more often, a high BLOCKSIZE will mean large memo file sections even for short code and both are not leading to a smaller footprint overall.
There is nothing unhealthy about this, though, it's just effecting the file size negatively, not the code speed or functionality and nothing gets broken. It also leads to large binaries (EXE/DLL) in BUILDs, so Dan's advice is a good idea.
Bye, Olaf.
Mike Lewis
Programmer
No, you don't have to do it for all your class libraries, but it does no harm to review the sizes from time to time, and to pack any that seem unusually large. I always do that before I do a build that I'm going to distribute, but I don't bother at other times.
By the way, this doesn't only affect VCXs. I also occasionally need to pack my form and report files (SCXs and FRXs).
The best advice is simply to keep an eye on the file sizes, and to pack when you think it necessary. By all means, write a PRG to do it for you - personally, I don't bother.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #7
Olaf Doschke
Programmer
mm0000,
well, it does not. Otherwise my experience wouldn't be EXE files growing larger with bloated VCXes, when building with "Recompile All".
Bye, Olaf.
well, it does not. Otherwise my experience wouldn't be EXE files growing larger with bloated VCXes, when building with "Recompile All".
Bye, Olaf.
Olaf Doschke
Programmer
What lines are you talking about? Code lines? Records?
We are talking about memo bloat here, not about deleted records.
I know the PACK does also pack the MEMOs, but in this case not. I know this bug since 2006, and it has never been fixed. Every larger EXE file created when not packing VCXes speaks for itself.
Your observation can be right, deleted records are removed, but VFP compile classlib is an internal, it may not use the same code as PACK to remove deleted records, it may only affect the DBF (vcx) part of the table and not the FPT (vct). That's how I experience it. You are thinking too narrow about PACK when you see deleted records removed.
Bye, Olaf.
We are talking about memo bloat here, not about deleted records.
I know the PACK does also pack the MEMOs, but in this case not. I know this bug since 2006, and it has never been fixed. Every larger EXE file created when not packing VCXes speaks for itself.
Your observation can be right, deleted records are removed, but VFP compile classlib is an internal, it may not use the same code as PACK to remove deleted records, it may only affect the DBF (vcx) part of the table and not the FPT (vct). That's how I experience it. You are thinking too narrow about PACK when you see deleted records removed.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question