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/15 Message-ID: <8fpu0g$a3e$1@nnrp1.deja.com>#1/1 X-Deja-AN: 623802765 References: <391E09C3.FA04871E@mailandnews.com> <9EET4.760$pN4.423580@news.pacbell.net> <3920DA5B.2F56@club-internet.fr> X-Http-Proxy: 1.0 x24.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Mon May 15 22:33:53 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-15T00:00:00+00:00 List-Id: In article <3920DA5B.2F56@club-internet.fr>, sikander@club-internet.fr wrote: > I think that a reduced executable size is important, since > that allows a better use of the CPU cache memory, so that > could improve the speed of the program. You are assuming that size of executable is directly related to the working set in cache. There is no reason to make this connection. Indeed it is obvious for example that static vs dynamic linking, which has no effect on cache usage to speak of, has a big effect on executable size. > > Concerning that problem, I suspect that, with GNAT, there is > not a good elimination of the unused code. 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. Similarly the presence or absence of debugging information has a huge effect on executable size, but the debugging info is not even loaded into memory, let alone the cache, if you are not using the debugger. I think to a first approximation, executable size of the null program, measuring the base size of the run-time, has nothing at all to do with execution efficiency. It may well have something to do with functionality (e.g. a fancy exception handler that prints out tracebacks will clearly take more space, but there is no reason to worry about this additional space). 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 :-) Sent via Deja.com http://www.deja.com/ Before you buy.