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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e9f27bbe0678fdfc X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: huge executable?? Date: 2000/05/16 Message-ID: <8frb2n$qcn$1@nnrp1.deja.com>#1/1 X-Deja-AN: 624013550 References: <391E09C3.FA04871E@mailandnews.com> <9EET4.760$pN4.423580@news.pacbell.net> <3920DA5B.2F56@club-internet.fr> <8fpu0g$a3e$1@nnrp1.deja.com> <3920F612.6790FBBC@maths.unine.ch> X-Http-Proxy: 1.0 x30.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Tue May 16 11:23:15 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-05-16T00:00:00+00:00 List-Id: In article <3920F612.6790FBBC@maths.unine.ch>, Gautier wrote: > > You are assuming that size of executable is directly related > > to the working set in cache. > > If it is not directly related, it does not mean that is not > at all! It depends on the granularity of the cache... Well sure, if you had a cache with 4K lines ... but in practice with real life hardware, the size of the working set in cache is completely unrelated to the size of the executable. > > Elimination of unused code will most certainly reduce > > executable size but it won't help one bit in reducing cache > > pressure, since > > obviously unused code never gets into the cache during > > execution. > > Again you suppose that the cache granularity is so small that > the cache will only contain bytes of executed code and not > parts of the adjacent code. Is it really the case ? I have > serious doubts! This effect, though theoretically there, is in fact far too small to be measurable. If you don't believe this, try some measurements. It's easy to do. By your theory, using gnatelim should speed up execution significantly. It won't! > > Basically the issue here boils down to disk costs alone. > > Seeing > > as 128K bytes is approximately $0.004 worth of disk space, I > > don't see this as a big worry these days :-) > And whatever the cost of storage people > are sometimes curious about "the loads of bloatware" that end > in an .exe, especially if it comes from an Ada compiler! I do not think bloatware is about the minimal size of trivial programs of no real interest from the point of view of actual software use. The reason people worry is they do not realize the x + y*c phenomenon and think instead, gosh if my one line program generates 128K, then what will 1000 lines generate? This of course is bogus worrying, and the point of a discussion like this is to explain that fact. Once again, if you are simply worried about the size of the EXE, just put the GNAT runtime library into a shared library. And magically the executables will get dramaticaly smaller (at least trivial executables will). Of course you have the inefficiencies and inconveniences of shared libraries when you do this, so you have to balance needs :-) Sent via Deja.com http://www.deja.com/ Before you buy.