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

[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.