[AccessD] Memory hit

Arthur,

A library in Access is an entire MDA file, including all code, queries,
tables etc.  The library is referenced or not.  If it is referenced, then
code is used, or not.  If no code is used, then the fact that the reference
is made is irrelevant, unless the link is broken.  If no code is used, then
(obviously) no code is loaded.

If code is loaded, then the entire contents of that module is loaded.
However the SOURCE code is not loaded, the Pcode is loaded.  Pcode is a
tokenized representation of the source code, created by the "compiler".  In
the case of VBA, source is "compiled" into Pcode.  The interpreter
interprets the Pcode.  It is important to distinguish between loading source
and loading Pcode because Pcode is MUCH smaller than the English text source
code.

If the source code is not compiled, then everything required to load the
current function, plus all of the other functions in the same module as the
current function is compiled "on demand" (into Pcode).  IOW, if a function
calls another function, then that other function is also compiled.  If that
other function is in another module, ALL of that other module is also
compiled (to Pcode) AND LOADED.

Back to the subject at hand, if a library contains 100 modules, and one of
those modules contains a single function to calculate PI, then one function
would be compiled (if required, i.e. not already compiled) and loaded into
memory.  It would stay there until the Access APPLICATION unloads, NOT until
ACCESS unloads.  IOW, if you closed Application A and loaded Application B,
then all code required for Application A would unload as Application A
closes.

If the function that calculates Pi is in a math module with 100 other
functions, then all 100 other functions in that math library would load.

Notice that this is true whether or not the module resides in a library or
is contained directly in your application.  A module is a module, and is
loaded exactly the same whether or not it is physically stored in an MDA
referenced by the app or is stored directly in the app.

My ENTIRE FRAMEWORK (Source and Pcode) are contained in a library whose
total size is about 4 megabytes.  Access.exe is "only" 6.473 megabytes (I
just checked), but when it loads any app it immediately claims 20 or more
megabytes of memory.  My main call center application is about 15 mbytes
container size.  The DATA on the other hand is HUGE.  

WINDOWS OTOH requires approaching 250 MEGS all for itself.

The point really is that this isn't your father's PCXT with 640KB RAM.  Why
in the world would I worry about whether my framework took 5 megs of space
when it loads?  I used to worry about it when the computers were running
Windows 98 in 32mb and the whole machine had 64 mb.  

I think you are grasping at straws to justify the use of cut and paste.
Personally I do not care if you do that, but you know as well as I do that
maintenance in a cut and paste world is a nightmare.  If you do not use your
code in multiple applications, then it makes absolutely no difference.  If
you do however, it makes all the difference in the world.  Application
specific code belongs in the application.  Non application specific code
does not!  Just that simple.

Now, as to whether a framework is overkill, that of course depends on
whether you like to code everything from scratch.  Windows is a framework.
I know that you have no use for windows, that all of the functionality to
read / write to the disk, screen, network ports etc are just of no use to
you, because as we all know, there is just a TON of stuff out there not
being used.  You would much prefer to just do it all yourself in Assembler,
which is course begs the question of why you are here on this list.  

Access is a framework, nothing more, nothing less.  It is a framework for
database access, designing forms, queries, reports and so forth.  But of
course, you have no need for that framework either, preferring to write the
whole thing in assembler.  SQL Server is a framework (for big iron
databases), Word is a framework (for creating / editing word documents),
Streets and trips is a framework (for mapping your trip).  ALL of these and
hundreds of other programs are applications in their own right, but provide
SERVICES to the programmer to expand what they do.  So, tell me one more
time that you do not need a framework.

My framework, or any other like it (and there are others, unfortunately I
cannot claim to have invented that wheel) simply provide functionality to
the application designer (in this case ME) to make the job of building an
application faster and easier.  By not having to reinvent the wheel every
time I start an application, I can have an entire application up and
functioning in a consistent manner, with a consistent look and feel, in
literally 1/10th the time that I would otherwise spend.  That of course
assumes that you care about consistent look and feel and operation.  

That does NOT mean that I do not have to build forms or reports or queries,
I do.  But what it does mean is that I can log things to disk, log things to
file, time the opening of forms broken down to user level, have a login and
a light weight security system that "just works" determining what controls
on a form a group of users can see, what forms they can open etc.  Sysvars
that can turn on/off framework functionality down to the form level.  JIT
subforms, dbl-click event handlers to open forms for editing / adding data
in lists behind combos, openargs parsed and ready for forms as they open.

Until you stop thinking of frameworks as the enemy, you can never come to
appreciate what they are, just a tool to make your life easier.  The
downside with Access is that there are no prebuilt frameworks available for
sale.  The upside is that you get to build your own.

So...

a) frameworks are overkill, because they drag in tons of stuff that is not
currently used and may never be used.

Yep.

b) a tool such as CodeLib or any similar thing is a better idea than
catch-all libraries, of which a large portion may never be invoked.

Nope.  There is a difference between a library and a module.  See above.
CodeLib (as I understand it) is a cut and paste tool.  I have to admit I did
that kind of thing back in the dark ages of coding.  Then I discovered
linkers...  That was (in my case) about 1987 or so, though they have been
around for decades longer.

c) even if only 20% of MyLib were invoked in the current app, invocation of
any sub or func in said library causes everything in said lib to be loaded
into ram. This may be a faulty assumption, and I readily admit that.

Nope, there is a difference between a library and a module.  See above.

d) (strictly a personal thing) Any code not called in the overall execution
in an app ought not reside in said app. Occam's razor, so to speak. Note
that I say this as one who has developed a large-scale library that dragged
in hundreds of procs and functions whether you liked it or not. At the time,
it seemed like a good idea -- low budgets, short delivery times and so on --
but after years of experience I despise this notion, and all the code I
wrote based on this notion.

OK.  On a strictly personal basis, I will let that stand.  Please revert
promptly to using DOS.  Most of windows is probably never used and obviously
you should not be using it in your app.  Of course, most of DOS was never
used either so maybe you should revert to BASIC without an OS at all.  Then
again, how much of Basic was used in any given application?  Hmmm... I think
you should try and get a hold of one of those old TI calculators, the
programmable type.  Oh... Wait.... Man they had a TON of stuff that I for
one never used....  OK, wait, a 4 function calculator.  Yea, that's the
ticket.  I can absolutely guarantee that I used every one of those four
functions much of the time.  And the good news is that you can get one for
about a buck at a garage sale somewhere.

>You could describe this turn as a return to low-level languages like C. If
a function or proc is not called, it ought not reside in the package. End of
story.

LOL, yep, you are right of course.  Please go talk to talk to Steve Gibson,
of SpinRite fame.  You have a lot to discuss together.  Of course he will
get you truly religious indeed when he straightens you out on the idea that
'C' is a low level language.

In the meantime my clients use some flavor of Windows, mostly XP now (250
Mbytes loaded immediately), some version of Access / Office (20-50 mbytes or
more immediately loaded) and some version of my framework (5 mbytes
immediately loaded).  It pains me greatly that I had to suck up 5 megabytes
of their precious memory but they left me no choice.

Now I seriously don't want to start any war here...

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, June 09, 2007 8:18 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Memory hit

I know, and I sympathize, and I even do it myself, simply because it's so
easy to add an entire module even though I might, in this given app, require
only one or two functions in said module. I do it, too. But I'm hailing back
to my earlier days in lower-level languages and thinking that this is a
stupid approach to building an app.

I think that I want to include only the code that is actually used. In my
case, that means that I have to break a few modules into a few dozen
procs/subs; but I cannot help but think that rolling the whole WalMart
library/class lirbrary into each successive app is lousy programming.

A.