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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d89e2d213646aec8
X-Google-Attributes: gid103376,public
Path: 
 g2news1.google.com!news2.google.com!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 02 Jun 2004 17:09:52 -0500
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
References: <mailman.28.1086105372.391.comp.lang.ada@ada-france.org>
	<oVavc.34141$js4.3916@attbi_s51>
	<mailman.30.1086145552.391.comp.lang.ada@ada-france.org><c9kd3v$i1n$1@a1-hrz.uni-duisburg.de>
 <mailman.34.1086176483.391.comp.lang.ada@ada-france.org>
 <c9l0vo$pq3$1@sparta.btinternet.com>
Subject: Re: Mneson announcement and help request
Date: Wed, 2 Jun 2004 17:10:07 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID: <xK-dnZHKcKOszSPdRVn-ug@megapath.net>
NNTP-Posting-Host: 64.32.209.38
X-Trace: 
 sv3-6adjr5T3DdAnacbpR0mY8gqEWdsZiJZFvoCP+xsJ+56eBdW62n3p3KEOxQc3stHitwp7RHjAh5lvKqq!xeY0mFMb8S02yX30i3cRRISmztySJMqBw4RFAqmMypU1uuRdpReqHD1hvTHJjFDqb4c2+lVReA7H
X-Complaints-To: abuse@megapath.net
X-DMCA-Complaints-To: abuse@megapath.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.1
Xref: g2news1.google.com comp.lang.ada:1038
Date: 2004-06-02T17:10:07-05:00
List-Id: <comp.lang.ada>

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:c9l0vo$pq3$1@sparta.btinternet.com...
...
> If you look at the assembler for the nested instansiation that you found
slow, you will see lots
>of system calls to sort out stack. If you look at assembler for exception
raising and handling,
>you'll see similar calls to save the occurance, reraise an exception,
whatever. Try stepping
>through the GNAT exception mechanism (in particular a-except.adb) - still
look fast
>compared to a check for an End_Of_File?

Well, yes, because End_of_File for Text_IO is very expensive (it has to do
lookahead of as many as two characters, and doing so makes later Gets
expensive as well). But "End_of_File" (or indeed any function call) misses
the point.

Indeed, the issue is the number of raises (in all compilers) and the number
of handlers (in most compilers). The number of these should be relatively
small, because compilers don't (usually can't) make this fast. In
particular, you should never raise and handle an exception in a (tight)
loop. (Our style guide strongly discourages exception handlers in loops.)
But calling expensive functions is no help!

                      Randy.