From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Making elp.el behave like a real profiler Date: Tue, 16 Aug 2022 11:27:36 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8194"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Winston Carlile To: Winston Carlile via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 16 17:28:39 2022 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 1oNyUh-0001yD-CM for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 17:28:39 +0200 Original-Received: from localhost ([::1]:58172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNyUg-0002z9-6U for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 11:28:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNyTo-0002J3-Rn for emacs-devel@gnu.org; Tue, 16 Aug 2022 11:27:44 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64952) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNyTm-0007Zf-8A for emacs-devel@gnu.org; Tue, 16 Aug 2022 11:27:44 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E79F8100138; Tue, 16 Aug 2022 11:27:39 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 69E651000ED; Tue, 16 Aug 2022 11:27:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660663658; bh=UeY9X25xFZc92mGNVxV6vXtk5nsUOSocdCrC0r9bzao=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jt7HMg8dprhbxzelZry7KBM9mqBt1S3kTOa8l0mxeQ5P16i/jw698hve5lZcAq42Z cqbA1BTHKxjYxRQ4xKqLd4z/liGkYZPswFI8fE0qrhZVcHR1J5KuUOYLzvvCULzuWk Ne/76Ur3hJOKIReotNRDp+DtdmdEogjqRD5GuuTxas9/JqbOLmMfOWm+DrTDn36guE qhoEowq0JRgIzCa5QBQ3ZbBEQz+CYXyyicrPcIL9buQBXfINVLQ2ddUh+K8RLYrO3B MnVmVan/nz3HR6gXhHUYiKvKof6q/X6iJfiX+up9AEUQsXzpm6YxSe7CvGb382j/ZV cpGaR8g+KbbBg== Original-Received: from pastel (unknown [45.72.195.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 398821201D0; Tue, 16 Aug 2022 11:27:38 -0400 (EDT) In-Reply-To: (Winston Carlile via's message of "Mon, 15 Aug 2022 12:22:54 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293505 Archived-At: Winston Carlile via "Emacs development discussions." [2022-08-15 12:22:54] wrote: > I'm working on adding one level of context to function calls > in ELP reports, looking for implementation and usability feedback. Before we go any further: are you aware of the sampling based profiler available via `M-x profiler-start`? > 1) Is there a better way to programmatically access the call > stack than a dynamic binding hack? There's `backtrace-frame(s)`, but I'm not sure it qualifies as "better". > 2) How can I make the report more intuitive? Specifically > I'm worried about confusing people with the 0 call count > for f in the above example. How 'bout: Function Name Call Count g 1 ;; called once: `-? 1 ;; calls from functions not instrumented f 4 ;; called 4 times: `-g 1 ;; once from g `-f 3 ;; and 3 times from itself Admittedly, this shows the "reverse" from what you currently show. You'd have the property that for every function, the first line shows the total of the subsequent lines. For the other direction: Function Name Call Count g 1 ;; called once `-f 1 ;; called f once f 4 ;; called 4 times: `-f 3 ;; called itself 3 times In that version, for a given function, the first line's count is not directly related to the other lines's count (it can be smaller or larger). > 3) Maybe a hashmap would be better than a plist when the > number of instrumented functions is large. A plist is about as bad as it gets. An alist would be at least a bit more natural (plists only really make sense when they're written by humans). I'm not sure I understand the code correctly, but my quick reading of it suggest you have O(N^2) calls to `new-infovec`, which seems like a bad idea [ oh, and naming it without an `elp-` prefix is also a bad idea) ] since the call graph is probably not that dense, so you'd be better off allocating them more lazily. If you keep the O(N^2) infovecs, then I'd recommend hashtables, indeed, since every alist/plist will have N elements in it, here N will easily grow to be too big for alist/plist (alist/plist work OK for smallish number of elements only). Stefan