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-Thread: 103376,6575b47ba54cee7c X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!l16g2000hsh.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Reducing the size of executables produced by GNAT Date: Wed, 13 Feb 2008 07:52:45 -0800 (PST) Organization: http://groups.google.com Message-ID: <4b2cd4e1-c0dc-4cd5-9e3b-1c4955eb0f08@l16g2000hsh.googlegroups.com> References: <40e9c01a-8d31-4554-9d9b-18cce7834d56@s12g2000prg.googlegroups.com> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1202917965 23869 127.0.0.1 (13 Feb 2008 15:52:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Feb 2008 15:52:45 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l16g2000hsh.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040924,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:19772 Date: 2008-02-13T07:52:45-08:00 List-Id: First here are a couple hints: * compile with -Os (optimize for size) * strip the executable maximally Do not worry though that the machine executes 45 KB of instructions. Part of the executable contains data, which you cannot reduce but which is obviously not executable. But this is all besides the point. Your real problem is CGI. If you want performance, forget GCI. GCI is probably the worst way to do dynamic web sites and has been deprecated for the past 10 years or so. 120K or 45K or 10K CGI executables won't make a difference because the executable files will be in the buffer cache anyway. What does make CGI slow is creating a new process with environment variables, file descriptors, etc. and then the necessary inter-process communications between the web server and the scripts. And CGI does that for each incoming HTTP request: this is bad. The proper way is to write one executable that embeds the web server itself. The Ada Web Server library from AdaCore was designed specifically for this purpose. With AWS, your one executable will be larger but much, much faster than CGI. And, since you will not launch your application with each HTTP request but only once and leave it running all the time, dynamic linking will be an option. Your web application can be very simple. Start listening on port 80. For each incoming request, call an Ada procedure that responds to the request. Done. Now, if your web application has many clients, you may want to be able to service more than one request at a time. For this, use Ada tasking. Your program first creates a queue of incoming requests, then a fixed number of worker tasks. After the worker tasks are created, it starts listening on port 80. For each incoming request, instead of processing the request, it places it in the queue. Each worker task is an infinite loop that waits for a request to become available in the queue, takes it, processes it, sends the response to the client, and comes back. In either case (single-task or multi-task) you have a fixed number of tasks that are infinite loops waiting for user input. Thus you never have to fork() a new process. This is good. And, all of this is one single executable program. If this program is statically linked and contains, in its data segment, all images and web page templates necessary, then it never has to read from the disk at all, running entirely from memory. That's how you achieve performance and small footprint. Read the details in the AWS User's Guide. -- Ludovic Brenta.