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,FREEMAIL_FROM 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-18 13:01:57 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn3feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail From: Caffeine Junky Subject: Re: Creating really small binaries? Newsgroups: comp.lang.ada References: User-Agent: Pan/0.11.3 (Unix) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: "Stephen Leake" Message-ID: NNTP-Posting-Host: 12.245.48.122 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1024430516 12.245.48.122 (Tue, 18 Jun 2002 20:01:56 GMT) NNTP-Posting-Date: Tue, 18 Jun 2002 20:01:56 GMT Organization: AT&T Broadband Date: Tue, 18 Jun 2002 20:01:56 GMT Xref: archiver1.google.com comp.lang.ada:26299 Date: 2002-06-18T20:01:56+00:00 List-Id: On Tue, 18 Jun 2002 12:41:35 -0400, Stephen Leake wrote: Hmm, XLib is presumably a huge C library, so you've changed your mind on > that? > > Writing your own GUI on top of XLib may not be the best way to make the > in-memory image size smaller. You may not be as good a GUI programmer as > the people who wrote the existing layers :). I know I'm not! > > In addition, if the GUI layers are in shared libraries, are you counting > them as part of "your" executable image size? If not, then use as many > shared libraries as possible! > Good point. I must admit to being influenced by the guys over at radsoft.net(They wrote a windows explorer replacement in about 14kb). My basic assumption(although I could be mistaken) is that by avoiding additional layers(such as Gnome and KDE) it'll be easier to keep the size down and the speed up. > 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... 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. I want to prevent that, and keep the application running smooth as a babies butt. 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. I hope that helps a little. Caffinator