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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Markus_Sch=c3=b6pflin?= Newsgroups: comp.lang.ada Subject: Re: Profiling Ada binaries Date: Mon, 25 Jul 2016 09:01:05 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MdpKeRr+sx3LK7JQiK5aNw.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 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31148 Date: 2016-07-25T09:01:05+02:00 List-Id: Am 22.07.2016 um 17:05 schrieb Alejandro R. Mosteo: > Incidentally, you might want to try with callgrind / kcachegrind to compare > results. IIRC gprof is less accurate given that it instruments code with some > granularity while valgrind does not have that limitation. We tried that before, but *grind slows down performance too much, so we cannot profile the affected binary. (It's some kind of soft real time application, so we can't just let it sit and run over night.) It currently looks like we have some success with perf right now. The key seems to be to add "-fno-inline-functions-called-once" to the compilation flags to get any meaningful call stack. Markus