From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Profiling native-compilation Date: Fri, 23 Apr 2021 10:10:12 +0300 Message-ID: <83mttpo4rv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 23 09:11:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZpyG-0008jv-NI for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Apr 2021 09:11:24 +0200 Original-Received: from localhost ([::1]:39934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZpyF-0005mM-NE for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Apr 2021 03:11:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZpxH-0005JP-Lg for emacs-devel@gnu.org; Fri, 23 Apr 2021 03:10:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35494) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZpxF-0001Bz-CE; Fri, 23 Apr 2021 03:10:21 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4937 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lZpxE-00043S-PS; Fri, 23 Apr 2021 03:10:21 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268305 Archived-At: I tried to profile the code involved in native-compilation using profiler.el, but the results seem to omit most of the functions involved in that: the percents shown in the resulting profile are very low, which seems to hint that most of the CPU time is spent in places that profiler.el cannot identify. Is it possible to use profiler.el to produce a meaningful profile of native-compilation? If yes, how does one go about setting up such profiling? And if this is not currently possible, why isn't it, and can we do something to make the situation better? For example, for at least two C functions that are important to see in the profile -- GC and redisplay -- we did arrange to be shown in the profile. So if the problem is that most of the time is spent inside C code, perhaps we could do something similar in comp.c? I think this is important because native-compilation is quite slow, and at least I don't have a clear idea where most of that time is spent. Andrea, you said once that most of the time is spent in libgccjit functions, which I find strange, since those are basically parts of GCC code, and I don't think I ever saw such slow compilation times from GCC. So I guess there's more here than meets the eye, and I think we should work on getting a clear idea where the time is spent, so that we could improve it. For example, if indeed libgccjit is the main sink, we should ask the respective GCC developers to speed it up. Thanks.