GNU bug report logs -
#46350
28.0.50; touchpad-scrolling-eats-lots-of-cpu-samples
Previous Next
Full log
Message #17 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sat, 6 Feb 2021 21:34:29 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> > Please load mwheel.el (NOT the .elc file!), and then profile the slow
> > scrolling again and show a fully-expanded profile. That might help us
> > understand what part of mwheel-scroll takes the lion's share of CPU
> > cycles.
>
> Here's whole report expanded (btw can't find if there's expand-all feature?):
Yes, "C-u RET".
> 11593 91% - command-execute
> 11549 91% - funcall-interactively
> 11542 91% - mwheel-scroll
> 11536 91% - let*
> 11420 90% - condition-case
> 11381 90% - unwind-protect
> 11377 90% - let
> 11373 90% - cond
> 11372 90% - condition-case
> 10868 86% - funcall
> 324 2% - scroll-down
> 263 2% - jit-lock-function
> 255 2% - jit-lock-fontify-now
> 235 1% - jit-lock--run-functions
I cannot make sense out of this: this profile says that funcall takes
most of the time, and the function it calls, scroll-down, takes almost
no time? Does anyone have any idea what could be going on here?
If this is just some artifact of "M-x profile", and most of the time
is spent in scroll-down, then I'm not sure what can be done, nor why
you see something I don't. Do you use a large frame and/or a small
font? And how many mouse-wheel events Emacs receives in your
scenario, anyway?
Oh, and what happens if you raise gc-cons-threshold to a large value?
This bug report was last modified 4 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.