Re: Reducing the size of executables produced by GNAT

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.