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: Fri, 17 Aug 2018 11:36:03 -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 1534522735 3192 195.159.176.226 (17 Aug 2018 16:18:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 16:18:55 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: monnier@iro.umontreal.ca Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 17 18:18:51 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 1fqhSb-0000fR-Ro for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Aug 2018 18:18:50 +0200 Original-Received: from localhost ([::1]:35135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqhUi-0006QZ-9d for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Aug 2018 12:21:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqgnR-0007v1-PV for help-gnu-emacs@gnu.org; Fri, 17 Aug 2018 11:36:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqgnQ-0008DT-G5 for help-gnu-emacs@gnu.org; Fri, 17 Aug 2018 11:36:17 -0400 Original-Received: from mail-io0-x233.google.com ([2607:f8b0:4001:c06::233]:46502) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fqgnQ-0008DH-9n for help-gnu-emacs@gnu.org; Fri, 17 Aug 2018 11:36:16 -0400 Original-Received: by mail-io0-x233.google.com with SMTP id x5-v6so7207957iop.13 for ; Fri, 17 Aug 2018 08:36:16 -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 :cc; bh=CsCn8uYDKDNtwo9M5tk/CG+M5zXPBp4BObCMtyXU+FM=; b=eaG1gBnfF5n4aJQW1F3n/lIgzzIWkkox3lK+Y1x6dFjHNattKwqsmJ0vpmkayFtoFJ B1ib2Qbh7W0RGk5gI8cTPs9Qwgjs2cdvreuh6OAdqEyEdw9DFnfL70DJ6KH+Y7CrooQd mWG/XUipswE+zChbj+jsG1jPj82BEzhCalhnmTkBFSTnNBhpreW/UnoVTkB1oWk7JUrX MxzUFz8m/HWeR7l5QeZCBq0xr1E5Y2P0W9noeY1Lt0DttcS8kVlidBdf7J4eeHDULfr9 QikhR8HHrpQUgABdt0jMUkMmr0nT9zPHcnM8fS5NFWmi4mLOv7CKgDNiAMMgnStttaA3 0kWw== 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:cc; bh=CsCn8uYDKDNtwo9M5tk/CG+M5zXPBp4BObCMtyXU+FM=; b=Cjxqo+cRpRMxH/SDeT2LYegZI6yU8noOnpm+3V7gbTHtXHSW/T4Ub4k34mwWuGMjvY auTDZ0S0hlxNDWoU3nAIlwNAucXn0bok8kScbrOqFzNnkkqIjGnKQ5QpjHjquyR6ugJo TDLvtLwumCtBPQvyGa2PCc+sQgJFCMSMxzT4y1336NmvXt7XhcyHYNvPH96y1ze7Qxme P8eZaHmwvu05YVSFSKxXP6nxjHpa0BpTGO2yoI+cWHVDr5LuNDOxm+oBJ4VoN/4NB5FL ClGzFpNc6/sfdShrSuqC4MN9+bbM+xS5VB4rADTX1X6YYWxLeFoGKXQ5GdSv3TobPCQu 3KBQ== X-Gm-Message-State: APzg51Az0VNspG6hGUS77qoGiJKrhZwloUVxoTnSgOdY+/xu8VfKqKS9 3EbrUhrzEcyG1iglGsWf3ox/cgeMOlmtmZfLN5U= X-Google-Smtp-Source: ANB0VdYpcYRs0tlQTyq6uv5m/up4nzNQEHy5Hx8ZjlZtVpYb37gUBBQKGd1sCd9SBcptfXWs0Sw1KH9cLkKeCQigNO0= X-Received: by 2002:a6b:c8ce:: with SMTP id y197-v6mr1764180iof.295.1534520175441; Fri, 17 Aug 2018 08:36:15 -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::233 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:117687 Archived-At: Byte compiling the file didn't seem to have much effect: let* was still blamed for the vast majority of the runtime (57%). I verified that the byte compiled version was the one loaded with M-x locate-library, which returned the .elc version of the library. Eliminating the let* by inlining its intermediate variables led to interesting results: - command-execute 1737 92% - call-interactively 1737 92% - apply 1737 92% - call-interactively@ido-cr+-record-current-command 1737 92% - apply 1737 92% - # 1737 92% - funcall-interactively 1737 92% - ftf-find-file 1732 92% - ftf-project-files-alist 1641 87% - ftf-project-files-hash 1425 75% - let* 1425 75% - mapcar 1112 59% - # 1104 58% - puthash 1092 58% - cons 884 47% gethash 188 10% + split-string 265 14% + maphash 212 11% + ido-completing-read 83 4% mapcar 4 0% + profiler-report 5 0% + ... 138 7% + timer-event-handler 1 0% The interesting parts here: - The overall number of CPU samples didn't change, I think indicating that eliminating the let* didn't in fact speed up the code. (In both cases, I ran ftf-find-file once, which took 4-5 seconds.) - The samples that were originally blamed on let* are instead blamed largely on cons and gethash now, which in my opinion seems more likely My suspicion here is that let* and the profiler are having some bad interaction where the samples are incorrectly being attributed to let* when they should be instead attributed to code called within the let*. Stefan, do you think I'm interpreting this correctly? On Thu, Aug 16, 2018 at 6:47 PM Stefan Monnier wrote: > > I'm trying to profile the usually excellent `find-things-fast` package to > > figure out why it's slow in my project. > > The presence of `let*` in the profile indicates that the code is not > byte-compiled. The difference in performance when byte-compiled can be > large enough, so I'd suggest you first byte-compile your code and only > then would I recommend you profile it (if still needed). > > > - # > 1024 51% > > - let* > 1008 50% > > cons > 24 1% > > This suggests that a lot of time is spent in `let*` which may simply be > because # is called many many times and doesn't do > much more than `let*`. > > Looking at your function, I'm indeed surprised that even tough this > `let*` was found 1008 times none of those times also found > file-name-nondirectory or expand-file-name or gethash in the stack. > > Maybe this hints at a bug in the profiler code. Can you try and run > this code many more times, so as to increase the "1008" to a larger > number, making it yet more statistically unlikely that none of > file-name-nondirectory or expand-file-name or gethash are found? > > > Stefan > > >