bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34809: 27.0.50; Too small number of samples in (benchmark-run-compil


From: Konstantin Kharlamov
Subject: bug#34809: 27.0.50; Too small number of samples in (benchmark-run-compiled …)
Date: Mon, 11 Mar 2019 21:40:58 +0300

Thanks for testing! The bug can be closed since, as I mentioned in prev. mail, updating to kernel 5.0 fixes it.

В Пн, мар 11, 2019 at 9:20 ПП (PM), Eli Zaretskii <eliz@gnu.org> написал:
 From: Konstantin Kharlamov <hi-angel@yandex.ru>
 Date: Mon, 11 Mar 2019 00:19:45 +0300

 Result of (benchmark-run-compiled …) has suspiciously unevenly
distributed numbers. E.g. it might give all 100% to garbage collector, as if no other code was ran. This was found as part of thread about slow
 lexical-binding, and I was asked to report it.¹

1: http://lists.gnu.org/archive/html/help-gnu-emacs/2019-03/msg00056.html

 # Steps to reproduce (in terms of terminal commands):
      1. wget
https://gitlab.freedesktop.org/libinput/libinput/raw/9a2d6f55b1276da11dd9b2c4c8e22a405576dfea/src/libinput.h
      2. emacs -Q --eval "(progn (find-file \"./libinput.h\")
 (profiler-start 'cpu) (benchmark-run-compiled 10
 (c-font-lock-fontify-region 0 (point-max))) (profiler-report))"

 ## Expected:
     Some of percentages should be inside cc-mode code.

 ## Actual:
      - ...           1 100%
         Automatic GC 1 100%

Not reproducible on my system (I get a reasonable profile, with over
100 lines, which points to font-lock-fontify-keywords-region and
c-find-decl-spots as two likely bottlenecks).

So I think Glenn is right, and this has something to do with your
kernel.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]