[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: |
Eli Zaretskii |
Subject: |
bug#34809: 27.0.50; Too small number of samples in (benchmark-run-compiled …) |
Date: |
Mon, 11 Mar 2019 20:20:33 +0200 |
> 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.