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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Profiling Ada applications using gprof
Date: Wed, 5 Dec 2018 18:27:50 +0100
Organization: Aioe.org NNTP Server
Message-ID: <pu91qn$ndu$1@gioia.aioe.org>
References: <8441254e-f634-4077-b8d9-d988dab3406c@googlegroups.com>
 <5846093f-ace9-4c8b-b4d7-d714b787d477@googlegroups.com>
 <b2a3692e-a53d-4be2-96d2-510400b08ffd@googlegroups.com>
 <27bf087a-d64d-4e9f-89b8-e7a7df70f917@googlegroups.com>
NNTP-Posting-Host: 6RgwMQWCXnjFVePlk7FG5g.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.2
X-Notice: Filtered by postfilter v. 0.8.3
Content-Language: en-US
Xref: reader01.eternal-september.org comp.lang.ada:54964
Date: 2018-12-05T18:27:50+01:00
List-Id: <comp.lang.ada>

On 2018-12-05 17:05, joakimds@kth.se wrote:
> When Writing code oneself one could use select-statements to discover long running entry calls like:
> 
>     procedure Work is
>     begin
>        select
>           delay 1.0;
>           Ada.Text_IO.Put_Line ("Calling A.Stop takes too long time!");
>        then abort
>           A.Stop;
>        end select;
>     end Work;
> 
> But again, it would be cool if there was a way to discover long running entry calls by profiling (for example gprof).

This is not an entry call, it is asynchronous transfer of control (RM 
9.7.4).

Regarding entry calls, a long running call of a protected entry is a 
bug, protected actions must be instant, nothing to profile. For a task 
entry, it is maybe not a quite bug, but suspicious nonetheless. Though, 
I presume that both must be detectable by the profiler.

I guess you mean something completely different - times spent by a task 
in a queue of an entry, multiple entries if requeue happens. That would 
be a quite cool feature indeed.

The total time of an entry call as observed by the caller is

    time spent in the queues + execution time of the entry body

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de