Results 1 to 8 of 8

Thread: [RESOLVED] Type library + Memory gain

  1. #1

    Thread Starter
    Junior Member
    Join Date
    Jan 2011
    Posts
    31

    Resolved [RESOLVED] Type library + Memory gain

    Hi everyone,

    Developpers in my company maintain a big vb6 project containing a lot of public constants, global variables and routines. They experience a memory problem while trying to compile the project totally for several weeks.

    One developper has created a DDL made up of several functions cut from the project and then, the memory problem did not occur until more code was adding into the project few weeks later.

    On my own, I have created a type library made up of several constants cut off from the project and it seems to ease compilations as well but until when...

    I do not like testing to understand a software logic so I would like the most precise information about the following topics. I googled for a while but with no success

    -> Are DLL and type libraries useful to solve the compilation memory problem and why ?

    -> How DDL and type libraries are managed in memory ?

    -> How components of a vb6 project (e.g. functions, constants, global variables) are organized in memory ? Are memory segments (e.g. code segment and data segment) allocated similarly to a C program ?

    I thank you in advance.

  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Type library + Memory gain

    A type library is only going to help a little bit. Almost anything that ends up taking space in the compiled program is going to take up space whether you use inline constants or a type library, though constants not actually used won't be compiled into the program.

    Your problem might actually be too many identifiers rather than a memory problem.

    Project Limitations

    A single project can contain up to 32,000 "identifiers" (any nonreserved keyword), which include, but are not limited to, forms, controls, modules, variables, constants, procedures, functions, and objects. Note that the actual number of identifiers is limited to available memory.

    Variable names in Visual Basic can be no longer than 255 characters, and the names of forms, controls, modules, and classes cannot be longer than 40 characters. Visual Basic imposes no limit on the actual number of distinct objects in a project.
    Too many identifiers in a Project can produce an "out of memory" error.

    Here's a blob of text (hard to link to) listing some additional details. It is rough so take some of it with a grain of salt:
    32000 identified per project
    Variable names must be 255 chars or less. Form/Control/Module/Class names must be 40 chars or less
    Only 254 control names per form (control arrays count for 1). Control array indexes from 0 to 32767
    Only 25 levels of nested controls
    ListBox/ComboBox limited to 32K items (1K per item)
    Std TextBox limited to 64K
    Labels limited to 1K
    Menus limited to 235 chars
    Control names limited to 40 chars
    Control Property names limited to 30 chars
    A line of code can only be 1024 bytes
    A std module is limited to 65534 lines
    Up to 256 blank spaces can precede the text on a line
    You may only use 24 line continuation characters for a logical line.
    Each procedure may be up to 64k of code.
    VB uses tables to store the names of identifiers (variables, procedures, constants, and so on) in your code. Each table is limited to 64K.
    Roughly 1,500 DLL entry point declarations allowed per module/form.
    32K case-sensitive unique identifiers per project.
    Every reference to an identifier in a different module creates an entry in the Import Table. Each such entry is a minimum of 24 bytes and is restricted to 64K, resulting in roughly 2,000 references per module.
    The Module-Entries table accepts up to 125 bytes per module, with a total limit of 64K, resulting in about 400 modules per project.
    The data segment (data defined in the Declarations section) of a form or module is limited to 64K. This contains: static local variables, module level variables (except arrays and variable length strings), 4 bytes for each module level array and variable length string.
    UDTs cannot excede 64K (variable length strings only count for 4 bytes).
    Total stack size is 1MB per thread (but may grow beyond this is there is adjacent free memory).
    In general the worst thing you can do is plop a bunch of global stuff into static (BAS) modules. You are much better off designing appropriate Class modules where appropriate, which avoids things like the giant static code and data segments of a BAS module. A Form or a UserControl is a special kind of class, so similar advantages accrue though most of the time you'll never create more than the default instance of a Form class.

    The way code and data segments are built is very similar to a C/C++ program. For native code compiles VB6 actually uses the 2nd pass of the VC++ 6.0 compiler (a special build as C2.EXE instead of C2.DLL). This just happens more automatically (and thus more obscurely) in VB6.


    The other consideration is to break programs up into separate Projects instead of one monolith. Factor out appropriate items into UserControls and Classes and put them into separate OCX and DLL Projects. This really should be a design issue up front before 1 line of code is written, but sadly there are a lot of poor programmers out there.

  3. #3
    Hyperactive Member
    Join Date
    Jul 2010
    Posts
    273

    Re: Type library + Memory gain

    Superb explanation; concise and to the point!

    In case David is not too used to VB, I just elaborate a little bit about the demerit of using BAS in the context of what Dilettante has specially referred to. For example, a "handle", an object and/or an array created for global use might easily be left uncleared. People tend to be more conscious of clearing the said items on terminating a class initiated by a calling Form or routine.

  4. #4
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: Type library + Memory gain

    Quote Originally Posted by petersen View Post
    ....People tend to be more conscious of clearing the said items on terminating a class initiated by a calling Form or routine.
    On the other hand a class doesn't necessarily need to clear public variables/objects/arrays because they will be destroyed when the class is terminated. But in saying that, clearing memory ahead of time and/or immediately when done with them is more ideal.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  5. #5

    Thread Starter
    Junior Member
    Join Date
    Jan 2011
    Posts
    31

    Re: [RESOLVED] Type library + Memory gain

    It is weird.... I have created a single VB6 project containing 16 standard modules and each of them contains 2000 declarations of public constants. Here is the approximative number of identifiers :

    Total = Number of constants + Number of modules + Sub main procedure

    <=> (16 * 2,000) + 16 + 1

    <=> 32,017

    Provided that the maximum of identifiers in a single VB6 project is 32,000 then I would normally not be able to compile totally the project. I try and the compilation does not raise any error.

    I think that the available memory limit applies in my case but I thought in a first palce that the 32K limit was more priority. Does someone understand why I can compile my single VB6 test project ?

    Thanks in advance for your help.

  6. #6
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [RESOLVED] Type library + Memory gain

    Per this MSDN link
    Project-Name Table
    The entire application uses a single table that contains all names. These include:

    •Constant names
    •Variable names
    •User-defined — type definition names
    •Module names
    •DLL-procedure declaration names

    The project name table is unlimited in total size, but is limited to a total of 32K case-sensitive unique entries. If the limit is reached, reuse private identifiers in different modules to limit the number of unique entries to 32K.

    Import Table
    Every reference to an identifier in a different module creates an entry in the Import Table. Each such entry is a minimum of 24 bytes and is restricted to 64K, resulting in roughly 2,000 references per module.
    Notice the term used: roughly. This may be why you were able to compile your test case.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: [RESOLVED] Type library + Memory gain

    By 32K they likely mean 32,767 and not 32,000. But "roughly" does mean just that. Sometimes there is a need to use some values for internal purposes or something.

    I am still having a hard time imagining a program needing so many named constants.

  8. #8
    Addicted Member
    Join Date
    Mar 2009
    Posts
    244

    Re: [RESOLVED] Type library + Memory gain

    I'm also having some problems with out of memory sometimes, and I was also looking for a solution to fix it without having to completely split up my project into several projects (I have too many bad memories dealing with OCX and versioning), also I like having everything in one big exe and don't want to keep older applications in mind with shared DLL's (it's also easier to maintain on the customer side, but that's just my point of view, as I said, I just have had too many DLL hell experiences)..

    But some questions I have:
    1.Do Type library definitions also add to the 'limited' list of identifiers within a project? Like moving all/a lot of constants to a type library save me a bunch of free entries in the project name table?
    2.Does any new item added to an existing enum add an entry to the project name table?

    I'm using DynaPDF (external DLL) for instance which has about a 100 private declares, would be moving all those declares into a Type library save me all those entries?

    I am still having a hard time imagining a program needing so many named constants.
    Well, with a big project (350 classes, 140 forms, only 7 own usercontrols, and a 24 modules) you tend to have a lot of different names, and I would even like to have more classes.. We're already resorting to control arrays on forms (but still a lot of forms aren't, and to refer to them from code you'll end up with using Enums, so in the end it doesn't really save a lot). Now I even sometimes just write a larger routine instead of splitting it up, just so it won't add another 'name' to the list..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width