From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!mcnc!ecsvax!tpmsph From: tpmsph@ecsvax.uncecs.edu (Thomas P. Morris) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <6105@ecsvax.uncecs.edu> Date: 15 Dec 88 14:43:08 GMT References: <6702@june.cs.washington.edu> <3861@hubcap.UUCP> <6713@june.cs.washington.edu> Organization: UNC Educational Computing Service List-Id: In article <6713@june.cs.washington.edu>, klaiber@june.cs.washington.edu (Alexander Klaiber) writes: > The method of using key searches is, I believe, an unnecessary hack to > avoid multiple references. Why bother to include a full B-tree package > or such when we can do without? > You mean to tell us that you =intend= to keep your "mailing" lists =permanently in memory=? You're =never= going to write them to a permanent file system/disk? Or that your never going to keep a list larger than can be kept in memory? Really! The method of using key searches is a useful aid to designing a program to read from a database larger than you can keep in memory, which needs to be permanent, and which ought to be well- behaved in terms of no =clobbering= other processes' performance! :-) Yeah, I know that the mailing list abstraction was only for an example. But a fairly poor example if you wish to justify structure sharing, which *has* its proper place... > Clearly, there is a tradeoff between readability and efficiency. In my > version, I reduce efficiency by requiring garbage collection (although > there exist rather powerful and fast GC algorithms). Your proposal > would definitely increase the complexity of the program and, due to the > overhead of a DB-lookup, might actually run slower than the version with > GC --- depending on circumstances such as frequency of lookups in the > database, size of the database (your program) vs. time required for GC, > amount of garbage produced etc. (my program). > For something like a database system (i.e. mailing lists, again), I would have to disagree that a keyed-search DB-lookup paradigm is necessarily less readable or understandable or complex than having to pre-process the databases (to create your structure sharing) to have direct access, which might not be reasonable or possible with a *large* database. Your points about speed of access are well taken, but consider the end user aspects: how many folks are going to wait 10, or 20, or 30 minutes for you to read in the external data, build your structure sharing structures, and =then= process their mailing list (personnel records, widget manufacturing data, etc), rather than using a relational database paradigm, using keyed access to those external permanent files? > In my opinion, people tend to put too much emphasis on plain efficiency of > their programs and too little on issues such as readability, reliability > and extensibility --- and I contend that (depending on the application) > garbage collection *CAN* help to improve all of these. Yes and yes. The mailing list example is and unfortunate choice perhaps. And some of us put also put an emphasis on how well a system works for its intended end-users! ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- -- ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph -----------------------------------------------------------------------------