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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,213fbc70eb225c16,start
X-Google-Attributes: gid103376,public
From: Rob Kirkbride <rk-comp@rk-comp.demon.co.uk>
Subject: 'others' - inefficient esp. DEC Ada? [1/1]
Date: 1997/10/12
Message-ID: <+3g7rFB7dIQ0EwNI@RK-COMP.DEMON.CO.UK>#1/1
X-Deja-AN: 279664222
Reply-To: Rob Kirkbride <rob@rk-comp.demon.co.uk>
Distribution: world
X-NNTP-Posting-Host: rk-comp.demon.co.uk [194.222.52.8]
Organization: Bedrock Corp.
Newsgroups: comp.lang.ada
Date: 1997-10-12T00:00:00+00:00
List-Id: <comp.lang.ada>


I am involved in a project using DEC Ada under Unix OSF1. We are at a
stage in the project now where we are improving performance, reducing
memory requirements etc.

While doing this study I was staggered to find that the 'others'
construct when used to clear an error eg.
My_Array := (others => Null_Element) can be 3-4 times SLOWER than
using a loop eg.

for My_Element in My_Array'range loop
        My_Array (My_Element) := Null_Element;
end loop;

This is because using the 'others' the array is built up in another part
of memory before being copied back to My_Array, apparently because
Null_Element could be a function and it may raise a constraint error.

Apart from the performance this also costs in memory as if this is done
in a task, the stack size of the task could have to be doubled to cope.
In one task this causes us to add 3Mb to the task size!

Obviously the others can be replaced with the loop but as we have over
6000 of them this could be quite expensive! We have asked DEC and they
admitted it was "poor optimisation". We would obviously like them to
improve this situation.

Does anyone know of a compiler that does this efficiently?

Anyone starting to write their coding standards I would seriously look
at this issue as you may find it will cause you to lose some performance
and memory (it has us)

I have attached a small test program to illustrate this point.

[ Section: 1/1 File: check_si.a Encoder: Turnpike Version 3.03 ]

begin 644 check_si.a
<encoded_portion_removed>
end

sum -r/size 19077/4149 section (from "begin" to "end")
sum -r/size 62565/2989 entire input file

-- 
Rob Kirkbride