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
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,af42f89f2159f3b6,start
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: A note on GNAT 3.05 performance
Date: 1996/06/20
Message-ID: <dewar.835245019@schonberg>#1/1
X-Deja-AN: 161200591
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-06-20T00:00:00+00:00
List-Id: <comp.lang.ada>


We have discovered a very significant performance issue in GNAT 3.05. It is
not exactly a bug, but it is certainly a very undesirable inefficiency.

Up to now, we have always arranged that the default calling sequence for
Ada should be the same as C. 

We discovered that there was one respect in which we did not follow this
rule in GNAT 3.04, namely we did not pass records in a manner consistent
with C. In C if you pass a record, a copy is always made, so that the
caller can mess with the record without changing the value in the caller.

So, we "fixed" this "bug".

The trouble is that the result is that all records get copied on calls
to all Ada subprograms. This has pretty significant efficiency consequences.
For example, all unbounded and bounded strings are records. 

Although the result is closer to our pure concept of making C and Ada
calling sequences the same, this clearly will not do. The reason that it
does not affect C much is that it is very unusual in C to pass records,
and it is especially unusual to pass large ones (instead pointers are
almost always passed).

So we will have to back this change out and figure out exactly the best
approach. We will plan to issue a 3.06 version fixing this problem early
next week. 

Sorry for the inconvenience. Note again that this is only a performance
issue, so if you don't have significant performance requirements, or don't
pass records around much, then it won't make a difference, but clearly
enough users are affected that it is worth issuing a new release.

This is one kind of bug that our test suites don't catch -- indeed we
*do* have a test whose fix depends on this undesirable change (it was
made in response to an error report!)

Anyway, I thought I would post this right away, so that perhaps you
might delay picking up 3.05 if you don't urgently need it and wait
the extra few days for 3.06.

Robert Dewar
ACT