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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,945d0baf2e74e805 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-19 08:53:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Creating really small binaries? Date: 19 Jun 2002 11:50:32 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1024502298 12195 128.183.220.71 (19 Jun 2002 15:58:18 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 19 Jun 2002 15:58:18 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:26388 Date: 2002-06-19T15:58:18+00:00 List-Id: Caffeine Junky writes: > On Tue, 18 Jun 2002 12:41:35 -0400, Stephen Leake wrote: > > Define the requirements for your application. Define the features you > > will need to meet those requirements. Design a system that is robust, > > easy to test, and probably efficient in terms of in-memory image size. > > while (not working) loop Compile it. Test it. end loop. See how big it > > is. Look for places to make it smaller. > > > > If you say more about your specific application, it might be possible to > > give more precise help. > > Generally I'm looking for some rules of thumb that I can apply to small > projects. Such as a Database UI, or a Text Editor, etc... Why is code size a criterium for either of these? They should not be "huge", but they don't have to be "small". Or at least, that's way less important than "does what I need, doesn't crash". > Right now I'm working on what will hopefully be a decent "E-Book" > reader that I could patch into a back-end database for storing > notes, annotations, bibliographies, etc... Something that can be > used for very large texts.(An Encyclopedia, The Bible, Collected > Works of Shakespear, The Common Lisp Standard, etc...). > > As you can imagine, the GUI work on this one would be rather extensive. I > plan on Open Sourcing it, so people will be free to critique it. > > Anyways, I hate having applications/libraries that just suck up oodles of > system resources all on thier own. Well, until you quantify "oodles", I'm not sure whether I agree or not. Applications should not use resources they don't really need, and they should attempt to reuse resources rather than simply requesting more. But if the "typical" machine has enough resources to run the app, I would not spend any time on making it more efficient. > I want to prevent that, and keep the application running smooth as a > babies butt. "Running smooth" and "using few resources" are not equivalent. Running out of resources was a typical problem in Windows 3.1, and may be a typical problem in embedded systems. But it should not be a typical problem for a database GUI. If it is, then I agree you need to pay attention to it. > GC is one way to go about it, and that's not out of the question. > But before going into implementing GC, I try to make sure the rest > of the app is as efficient as I can possibly make it. If by "GC" you mean "automatic recycling of resources", then put that in _first_! That _is_ they way to make the app "as efficient as you can possibly make it". Use Controlled types for any resources requested from the OS/GUI, so you can be sure they are released properly. -- -- Stephe