Arthur Fuller
fuller.artful at gmail.com
Sun Jun 10 06:01:04 CDT 2007
I agree with every point you made, Shamil. Arthur On 6/10/07, Shamil Salakhetdinov <shamil at users.mns.ru> wrote: > > <<< > 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. > >>> > Arthur, > > I should have added to my previous posting notes that in MS Access VBA, > VB6, > VB.NET, C# there is no 100% safe way to "compile out automagically" unused > code functions, methods, properties because of possible on run-time late > binding calls (MS Access VBA has also Eval(...) and Application.Run...)... > > Therefore the only answer is a good highly cohesive design of standard and > class modules: in that case the overheads of memory hit promise to be > minimal... > > The own costs of such design are very high: therefore I wouldn't even try > to > get such a good design from scratch - quite some code refactoring will be > needed until one gets such designs - as a consequence code copy & paste > doesn't look like a proper approach in general case but in the cases of > small "quick & dirty" projects and when stable library code is used then > copy & paste shouldn't be considered as a "big evil" IMO... > > -- > Shamil > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Sunday, June 10, 2007 2:30 AM > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >