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,99222a5bd46ef3c9
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: GOTO considered necessary (reworked)
Date: 1997/06/21
Message-ID: <dewar.866897452@merv>#1/1
X-Deja-AN: 251571693
References: <5nn2fm$11dk$1@prime.imagin.net> <dewar.866539123@merv>
 <EBxpxC.417@world.std.com> <dewar.866851059@merv> <EC3u70.Ksu@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-21T00:00:00+00:00
List-Id: <comp.lang.ada>


Bob said, replying to me

<<>First, you certainly can't eliminate the actual initializatoin and
>finalization (unless you are *very* clever indeed :-)

Of course.  That's not "overhead".  That's what the program want's to
do, and of course that code needs to get executed, in general.

>>

The context here was my observation that people used finalization too
freely in some cases, without worrying about the efficiency effects. The
actual finalization time is definitely a (perhaps the) most important
component of the casual inefficiency that unthinking use of controlled
types introduces. I never focussed on the overhead issue in the term
you are using.

<<Granted.  However, a program without aborts (or, without any tasking at
all) doesn't need that overhead.  That's what pragma Restrictions is
for.  I didn't say it's "easy" to eliminate this overhead -- I said it's
possible.

>>


The use of pragma Restrictions for this kind of improvement is in practice
not very usable. That is because you have to recompile the world, including
all libraries, to take advantage of such a restriction. If you have many
such partition wide configuration switches, you quickly need hundreds
or even thousands of different versions of your libraries. Thus in practice
the use of pragma Restrictions is not practical for general purpose
programming.

<<But the overhead I was thinking of was the overhead of automatically
putting controlled objects onto lists and taking them off, which is also
possible, but not easy, to eliminate.

>>


Well let's wait to see whether anyone actually claims to have done this
(eliminate all lists for finalization). It is *much* harder than it appears
(it reminds me of the infamous Haberman-Nassi optimization of rebdezvous --
such an obvious idea, but the devil (the one in the details) won out in that
case -- the paper was in fact never published because of fundamental
technical difficulties in marginal cases). I suspect you will find the
same thing here. It is interesting that a number of C++ implementations
are moving towards using lists as they struggle with trying to get
destructors to work "right" with exceptions.