[AccessD] Memory hit

Although it would seem a bit cumbersome, wouldn't separating the procs and
functions into separate files accomplish what you want - just include the
specific chunks of code that you need?  Sure you'd end up with 100 modules
in a code mdb instead of one but you could then import only the ones you
need making your app as compact as possible.

Rocky
 




 	
	

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, June 09, 2007 3:30 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Memory hit

I seriously don't want to start another war here. My gut takes your
perspective. The conclusions that I draw from this are:

a) frameworks are overkill, because they drag in tons of stuff that is not
currently used and may never be used.
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.
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.
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.

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.

Now, it may be that Access is smarter than most compilers/linkers, and when
your app calls one function in a library that contains 100 functions, it
loads only that one, plus the ancillaries that it calls. That could be. That
would be very nice, and I would love to learn that it's true. In the
meantime, I'm taking the attitude that one call into a library calls
everything in said library into memory. If I am right (which I readily admit
that I don't know), then the module-based notion is quite wrong, and except
for very narrowly defined universes, code ought not be packaged this way.

I will shoot myself, first.

In the current app that I am writing in Access, I have a module called
aaLib, which contains about 50 procs and functions that I use everywhere. I
also have another called Statics that contains all the static functions
pertaining to this app. There are modules called [Report Functions], [Form
Funtions] and so on. These latter modules probably do not contain anything
not app-specifc, but the aforementioned modules are guarateed to contain
code that has utterly no bearing on the current app.

So the net result of this approach is:

1. I can call any of the functions that I have added to the basic "Access
vocabulary".
2. If I call any one of these, I may incur loading all the functions in the
given library.

I have several of these. One is concerned with API. Another is devoted to
SQL. Another is devoted to Form functions, another to Report Functions.

I can drop any of these modules into the app I began designing yesterday,
but that app needs only about (say) 20% of the code stored in these modules
I drop in.

To be frank, I do it because nobody complains. But aside from the client's
perspective, I hate doing it this way. I don't want to drop in entire
100-function modules if I only need 11 of said functions.

This has led me to the conclusion that 100-function modules are the wrong
way to go. Similary, class libraries that drag in 40 classes when you named
only one are the wrong design. I am drifting toward the notion that each
file ought contain a narrowly specified group of functions or procs or
related classes; otherwise a whole lot of unrelated baggage gets dropped in.

This assumes that Access behaves like most compiled languages, which premise
is subject to scrutiny. I am not entirely sure how to check this, other than
to write a one-proc app that does nothing more than MsgBox and then add
several of my libraries to it, measuring the footprint before and after
adding said libraries.

Arthur


On 6/9/07, Shamil Salakhetdinov <shamil at users.mns.ru> wrote:
>
> Hi Arthur,
>
> AFAIK MS Access loads whole modules.
> Once loaded they stay in memory until MS Access quits.
>
> MS Access loads standard modules on demand - as soon as a 
> function/sub/property of a module is called this function's module is 
> loaded.
>
> Class modules' are loaded on class's instance creation.
> For class modules just one copy of module's code is loaded but every 
> instance has its own in memory copy of non static module level 
> variables...
>
>
> --
> Shamil
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur 
> Fuller
> Sent: Saturday, June 09, 2007 7:21 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Memory hit
>
> Suppose the following scenario:
>
> 1. I have a huge library of code, stored as classes or just functions 
> and procedures.
> 2. I drag this library into my current app.
> 3. 70% of the code in said library is un-used in said current app.
>
> What is the cost in terms of physical disk size (can this be 
> calculated?) and in terms of RAM? If I call one function in a library 
> that contains 30 functions, does Access load the one or all 30?
>
> A.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.13/840 - Release Date: 6/8/2007
3:15 PM