Shamil Salakhetdinov
shamil at users.mns.ru
Sun Jun 10 01:58:23 CDT 2007
Hello Arthur, As usual there is no one definitive answer on "religious debate" as CodeLib vs. Application Development Framework is.... <<< a) frameworks are overkill, because they drag in tons of stuff that is not currently used and may never be used. >>> Yes and No. Yes, they are overkill sometimes because they impose the structure, which isn't flexible enough for software development and then a lot of efforts are needed to "workaround the framework". No, the fact that MS Access loads whole modules is its technical limitation - AFAIKR even Turbo Pascal 4 (released middle-end of 80ies) was "smart enough" to remove all unused code from compiled executables. Delphi does that too AFAIK etc. <<< 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. >>> Yes and No. Yes, making tools as CodeLib is an easy and an inexpensive way to keep code, which can be quickly copied & pasted when needed. No, copy & paste is a "road to hell" for the code base, which isn't yet stable - in such cases support costs will become very high... <<< 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, >>> Unfortunately, it is not. <<< This has led me to the conclusion that 100-function modules are the wrong way to go. >>> Yes. <<< Similary, class libraries that drag in 40 classes when you named only one are the wrong design. >>> Yes. <<< This assumes that Access behaves like most compiled languages, which premise is subject to scrutiny. >>> Turbo Pascal, Delphi, Borland C++, MS Visual C++ (when optimization is on?), even VB6(?) when "Optimize for small code" option is on and I guess many other modern compilers (unlike MS Access/VBA) do "strip out" unused code from compiled executable... Arthur, but as you noted "100-function modules are the wrong way to go" and "drag in 40 classes when you named only one are the wrong design" - yes, that's true = *wrong design* is an "evil" to overcome. And here OOA&D principles are the answer - all that "low coupling", "high cohesion", software design patterns... But nothing is free in this world - when you get good *flexible* agile design then the size of the source code doubles(?) for advanced OO languages as C++/C#/VB.NET and gets four(?) times more code lines for VB6/VBA - have a look at this my exercise - http://smsconsulting.spb.ru/patterns/labs/ObserverPatternLab.htm. Recap ===== As usual in software development world "copy & paste CodeLib approach" vs. "Application Frameworks", "bad 100-functions modules design" vs. good "low coupled and highly cohesive" OO design etc. is a never ending "trade-offs + work-arounds" story with local successes and failures, which finally makes what is called in broad sense as "evolution"... Note: ===== The best software design I have ever seen was PDP11 RSX-11M's assembler code. This assembler code was available because RSX11-M installation is compiled from the sources after installation options are defined. Needless to say this assembly code wasn't OOP but the way is was "jam-packed" and manually (?) optimized was incredibly high. I'd think that modern compilers as Intel's C/C++, Delphi, C#/VB.NET/C++ (Visual Studio) do optimize the size of compiled code (when such optimization is requested) much better that it can ever be done manually... -- Shamil P.S. ========================================= Main Entry: trade-off (http://www.m-w.com/dictionary/trade-off ) Pronunciation: 'trAd-"of Function: noun 1 : a balancing of factors all of which are not attainable at the same time <the education versus experience trade-off which governs personnel practices -- H. S. White> 2 : a giving up of one thing in return for another : EXCHANGE - trade off transitive verb ========================================= Main Entry: work-around (http://www.m-w.com/cgi-bin/dictionary?va=work-around ) Pronunciation: 'w&rk-&-"raund Function: noun : a plan or method to circumvent a problem (as in computer software) without eliminating it ========================================= Main Entry: evo.lu.tion (http://www.m-w.com/dictionary/evolution ) Pronunciation: "e-v&-'lu-sh&n, "E-v&- Function: noun Etymology: Latin evolution-, evolutio unrolling, from evolvere 1 : one of a set of prescribed movements 2 a : a process of change in a certain direction : UNFOLDING b : the action or an instance of forming and giving something off : EMISSION c (1) : a process of continuous change from a lower, simpler, or worse to a higher, more complex, or better state : GROWTH (2) : a process of gradual and relatively peaceful social, political, and economic advance d : something evolved 3 : the process of working out or developing ... -----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