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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,9983e856ed268154
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: RUSSIAN,UTF8
Received: by 10.180.82.226 with SMTP id l2mr1196504wiy.1.1344850619248;
        Mon, 13 Aug 2012 02:36:59 -0700 (PDT)
Path: 
 n2ni107269548win.0!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news-feed.eu.lambdanet.net!texta.sil.at!news.stack.nl!aioe.org!.POSTED!not-for-mail
From: "Vasiliy Molostov" <molostoff@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Should Inline be private in the private part of a package spec?
Date: Tue, 07 Aug 2012 23:26:41 +0400
Organization: None
Message-ID: <op.wioqyrhjka8ora@aspire.local>
References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net>
 <e416cb92-6ec8-4514-8fa9-c35d6432b117@googlegroups.com>
 <wcc4noj4zof.fsf@shell01.TheWorld.com> <jvnchp$r5c$1@munin.nbi.dk>
 <wccr4rkqed5.fsf@shell01.TheWorld.com> <op.wiml9rw3ka8ora@aspire.local>
 <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net>
 <op.wim0pbprka8ora@aspire.local>
 <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net>
 <m2hasf10nc.fsf@nidhoggr.home> <op.win91lh8ka8ora@aspire.local>
 <m24noe1uiu.fsf@nidhoggr.home>
NNTP-Posting-Host: Xw13RWgh8yxgPSv0x3+H9w.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: Opera Mail/12.01 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable
Date: 2012-08-07T23:26:41+04:00
List-Id: <comp.lang.ada>

Simon Wright <simon@pushface.org> =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0)=
 =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=
=B5 Tue, 07 Aug 2012  =

21:28:25 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> writes:
>
>> Simon Wright <simon@pushface.org> =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0=
) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=
=B5 Tue, 07 Aug
>> 2012 14:01:27 +0400:
>
..
>
> which you would think would be a likely candidate for inlining.

Perhaps. Since it is an environment dependent, e.g. how internal data fl=
ow  =

in a resulting image is organized by a compiler (e.g. stack and register=
  =

alchemy) on a given hardware.

By using a word "pragma inline" we suppose, I think, "un-roll" expensive=
  =

call with many parameters, referencing them directly to locals.

This can increase perfomance in loops where such a call is used, and is =
 =

called many times. So, the more parameters we passed the more expensive =
 =

becomes that call. As parameter count goes to be less as the expensivene=
ss  =

goes to be less, too.

I am not sure that the expense becomes zero with a parameter count equal=
  =

to one, since it is a compiler (implementation) and architecture depende=
nt  =

thing, but indeed and doubtless, inlining in general can improve  =

perfomance with this  call-in-a-loop stuff.

It is my opinion only.

> I was agreeing that inlining may not improve speed.

Yes, may not.

-- =

=D0=9D=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE =D0=B2 =D0=BF=D0=BE=D1=87=
=D1=82=D0=BE=D0=B2=D0=BE=D0=BC =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B5=
 =D0=B1=D1=80=D0=B0=D1=83=D0=B7=D0=B5=D1=80=D0=B0 Opera: http://www.oper=
a.com/mail/