From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Charlie Andrews Newsgroups: gmane.emacs.help Subject: Re: profiler-report seems to be missing data? Date: Thu, 16 Aug 2018 09:47:30 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1534427776 11501 195.159.176.226 (16 Aug 2018 13:56:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 13:56:16 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 16 15:56:12 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqIl1-0002sc-UL for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Aug 2018 15:56:12 +0200 Original-Received: from localhost ([::1]:55772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqIn8-0002La-Gg for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Aug 2018 09:58:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqIcq-00009R-4i for help-gnu-emacs@gnu.org; Thu, 16 Aug 2018 09:47:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqIco-0000s8-Ld for help-gnu-emacs@gnu.org; Thu, 16 Aug 2018 09:47:44 -0400 Original-Received: from mail-io0-x22f.google.com ([2607:f8b0:4001:c06::22f]:35947) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fqIco-0000qr-E8 for help-gnu-emacs@gnu.org; Thu, 16 Aug 2018 09:47:42 -0400 Original-Received: by mail-io0-x22f.google.com with SMTP id m4-v6so3909964iop.3 for ; Thu, 16 Aug 2018 06:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SUslvw6e3vqa5XGGJ1/NsHz0TXJnhaAnDuUYH0kK1SY=; b=WQsBb+zw2mX9ZQMr4FjEgV5rBqRktQYmATEJLfEIIGek98UL+sVmcfMP/WwMdNJdF6 wGoX+a5kzSYQkDGZrJUoD9ArCYlykPZG1H2yfU1NW4jIBh/2/U5q8NU5rsC/s2BDoXvZ 5PgorjMMUH7vQhvzFMdzRcMvsMfcdBsnz6Yzk6Vn8macTzoMVx6xdSns08wq/0sssCq3 SXcAPl/mDuJ2IdXlF5OuSu22YHXofbgyMsn3va1F9u2HdMOwu3FpbQ0x5lZgIkIbsq2U hMJdowLWPvq7CaAJTNdhLDTAdiVVSTd/zYdrN+HFslkVjrGz4Xf5A3/Xyu2bCSQb4i2x kYqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SUslvw6e3vqa5XGGJ1/NsHz0TXJnhaAnDuUYH0kK1SY=; b=g3R/2tcWxYp+BDxWmYoWUvv7MC5DtTZmP3BeUufrTVTXNDDeI1OsDZkH9F+upqeteq Rc06EbDigUs8TXy9S1kV4YM9137FSnlbHi2Esk9K4kXHqmQZtW/69fxp6Ti4bPmaybvl vEKq4QTESSQIXZ7KIpFoOJJQTWjLsy+mpOhrfksU5H3MOq/CW/CUpm32HcrN3d73jFF4 pa+ddKT6BxoKyIO1ZHqO1mslKZyh5zmMkNqUAlKNrzwIyivV8R3mCZDPGYCo+VgiHfNU HErARnWJSks9ed2qNGKX3q3mlTFa7tBCf0yZxXhIQzgELff+hbaNu5LRn4r1XQawXF1L xAQQ== X-Gm-Message-State: AOUpUlG7tOrubdKkwfRQmvp1aogKhnmlhWzdE9FZmTHVveZfB/C+9jST aE//BK75zfyUVu3atsNJSm+V1Rrb3XbPdETrJ3gWEg== X-Google-Smtp-Source: AA+uWPyCV7VTAnZjKGxbMdIGtgB9FfYtyXXtrkX3Pfk++ilHE3RjTiCWAfDBKhNIK0I557SJv9uo2l2xxS0tA1gODY8= X-Received: by 2002:a6b:fe14:: with SMTP id x20-v6mr26883636ioh.159.1534427261177; Thu, 16 Aug 2018 06:47:41 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::22f X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:117670 Archived-At: (I apologize if this messes up the threading - I saw Eli's response on lists.gnu.org, but the mail didn't show up in my Gmail inbox. I'm replying to it here.) The version of the package that I'm profiling is unfortunately not byte compiled. I did this by running M-x locate-library find-things-fast , which returned "~/github/find-things-fast/find-things-fast.el". This is my local development version of the library, not the ELPA version of the library which also includes the byte-compiled version. If I remove that github version from my path and reload emacs, the same command reutrns "~/.emacs.d/elpa/find-things-fast-20150519.1526/find-things-fast.elc" (the byte compiled version) as expected. I'm just not sure why a non byte-compiled version would be so sparse on details regarding what functions are taking up time. On Wed, Aug 15, 2018 at 11:00 AM Charlie Andrews wrote: > I'm trying to profile the usually excellent `find-things-fast` package to > figure out why it's slow in my project. > > I started profiling with `profiler-start`, executed the command that's > slow (`ftf-find-file`), then immediately ran `profiler-report`. > > This generated the following report: > > Functions CPU samples > % > - command-execute 1770 > 88% > - call-interactively 1770 > 88% > - apply 1770 > 88% > - call-interactively@ido-cr+-record-current-command > 1770 88% > - apply 1770 > 88% > - # 1770 > 88% > - funcall-interactively 1770 > 88% > - ftf-find-file 1597 > 80% > - ftf-project-files-alist 1522 > 76% > - ftf-project-files-hash 1330 > 66% > - let 1330 > 66% > - mapcar 1330 > 66% > - # 1024 > 51% > - let* 1008 > 50% > cons 24 > 1% > + split-string 282 > 14% > + maphash 192 > 9% > + ido-completing-read 67 > 3% > + next-line 75 > 3% > + ido-switch-buffer 41 > 2% > + ido-switch-buffer-other-window 38 > 1% > + profiler-report 19 > 0% > + ... 145 > 7% > + redisplay_internal (C function) 37 > 1% > + timer-event-handler 26 > 1% > undefined 5 > 0% > + gui-set-selection 4 > 0% > internal-echo-keystrokes-prefix 2 > 0% > > The profiler report seems to blame the `let*` function within > `ftf-project-files-hash`. > > However, looking at that function: > > (defun ftf-project-files-hash () > "Returns a hashtable filled with file names as the key and " > (let ((default-directory (ftf-project-directory)) > (table (make-hash-table :test 'equal))) > (mapcar (lambda (file) > (let* ((file-name (file-name-nondirectory file)) > (full-path (expand-file-name file)) > (pathlist (cons full-path (gethash file-name > table nil)))) > (puthash file-name pathlist table))) > (split-string (ftf-project-files-string))) > table)) > > It seems incredibly unlikely that `let*` is the slow part, but rather one > of the functions called within that `let*`. > > Why is `profiler-report` stopping at `let*` rather than telling me which > component of that `let*` is slow? How can I dig deeper to find which > exactly function is slow? > > (FWIW, I've tried increasing profiler-max-stack-depth from 16 to 30 to no > avail.) >