Question about bignum usage

Question about bignum usage

[Gerd Möllmann]

In the igc branch, I see that Emacs creates bigints in an rate that I
find astonishsing, thousands in a few minutes. Most backtraces look like
this.

  * frame #0: 0x00000001000f9ce8 emacs`make_integer_mpz [inlined] make_bignum_bits(bits=71) at bignum.c:99:7 [opt]
    frame #1: 0x00000001000f9ce8 emacs`make_integer_mpz at bignum.c:170:10 [opt]
    frame #2: 0x00000001001beb48 emacs`decode_time_components(form=TIMEFORM_HI_LO_US_PS, high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfde50, dresult=0x0000000000000000) at timefns.c:812:27 [opt]
    frame #3: 0x00000001001be7e4 emacs`list4_to_timespec(high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfdec0) at timefns.c:1008:7 [opt]
    frame #4: 0x00000001000e1c98 emacs`timer_check [inlined] decode_timer(timer=(struct Lisp_Vector *) $2 = 0x000000010ab42538, result=0x000000016fdfdec0) at keyboard.c:4648:10 [opt]
    frame #5: 0x00000001000e1c54 emacs`timer_check at keyboard.c:4713:10 [opt]
    frame #6: 0x00000001000e1b44 emacs`timer_check at keyboard.c:4856:18 [opt]
    frame #7: 0x00000001000df51c emacs`detect_input_pending_run_timers [inlined] readable_events(flags=1) at keyboard.c:3577:5 [opt]
    frame #8: 0x00000001000df518 emacs`detect_input_pending_run_timers [inlined] get_input_pending(flags=1) at keyboard.c:7859:42 [opt]
    frame #9: 0x00000001000df508 emacs`detect_input_pending_run_timers(do_display=true) at keyboard.c:11563:5 [opt]

Is this expected?

Re: Question about bignum usage

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 20 Jun 2024 07:59:36 +0200
> 
> In the igc branch, I see that Emacs creates bigints in an rate that I
> find astonishsing, thousands in a few minutes. Most backtraces look like
> this.
> 
>   * frame #0: 0x00000001000f9ce8 emacs`make_integer_mpz [inlined] make_bignum_bits(bits=71) at bignum.c:99:7 [opt]
>     frame #1: 0x00000001000f9ce8 emacs`make_integer_mpz at bignum.c:170:10 [opt]
>     frame #2: 0x00000001001beb48 emacs`decode_time_components(form=TIMEFORM_HI_LO_US_PS, high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfde50, dresult=0x0000000000000000) at timefns.c:812:27 [opt]
>     frame #3: 0x00000001001be7e4 emacs`list4_to_timespec(high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfdec0) at timefns.c:1008:7 [opt]
>     frame #4: 0x00000001000e1c98 emacs`timer_check [inlined] decode_timer(timer=(struct Lisp_Vector *) $2 = 0x000000010ab42538, result=0x000000016fdfdec0) at keyboard.c:4648:10 [opt]
>     frame #5: 0x00000001000e1c54 emacs`timer_check at keyboard.c:4713:10 [opt]
>     frame #6: 0x00000001000e1b44 emacs`timer_check at keyboard.c:4856:18 [opt]
>     frame #7: 0x00000001000df51c emacs`detect_input_pending_run_timers [inlined] readable_events(flags=1) at keyboard.c:3577:5 [opt]
>     frame #8: 0x00000001000df518 emacs`detect_input_pending_run_timers [inlined] get_input_pending(flags=1) at keyboard.c:7859:42 [opt]
>     frame #9: 0x00000001000df508 emacs`detect_input_pending_run_timers(do_display=true) at keyboard.c:11563:5 [opt]
> 
> Is this expected?

Why not?  Time values are known to produce bignums, yes.  What does
list-timers show on that system?

Re: Question about bignum usage

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Thu, 20 Jun 2024 07:59:36 +0200
>> 
>> In the igc branch, I see that Emacs creates bigints in an rate that I
>> find astonishsing, thousands in a few minutes. Most backtraces look like
>> this.
>> 
>>   * frame #0: 0x00000001000f9ce8 emacs`make_integer_mpz [inlined] make_bignum_bits(bits=71) at bignum.c:99:7 [opt]
>>     frame #1: 0x00000001000f9ce8 emacs`make_integer_mpz at bignum.c:170:10 [opt]
>>     frame #2: 0x00000001001beb48 emacs`decode_time_components(form=TIMEFORM_HI_LO_US_PS, high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfde50, dresult=0x0000000000000000) at timefns.c:812:27 [opt]
>>     frame #3: 0x00000001001be7e4 emacs`list4_to_timespec(high=<unavailable>, low=<unavailable>, usec=<unavailable>, psec=<unavailable>, result=0x000000016fdfdec0) at timefns.c:1008:7 [opt]
>>     frame #4: 0x00000001000e1c98 emacs`timer_check [inlined] decode_timer(timer=(struct Lisp_Vector *) $2 = 0x000000010ab42538, result=0x000000016fdfdec0) at keyboard.c:4648:10 [opt]
>>     frame #5: 0x00000001000e1c54 emacs`timer_check at keyboard.c:4713:10 [opt]
>>     frame #6: 0x00000001000e1b44 emacs`timer_check at keyboard.c:4856:18 [opt]
>>     frame #7: 0x00000001000df51c emacs`detect_input_pending_run_timers [inlined] readable_events(flags=1) at keyboard.c:3577:5 [opt]
>>     frame #8: 0x00000001000df518 emacs`detect_input_pending_run_timers [inlined] get_input_pending(flags=1) at keyboard.c:7859:42 [opt]
>>     frame #9: 0x00000001000df508 emacs`detect_input_pending_run_timers(do_display=true) at keyboard.c:11563:5 [opt]
>> 
>> Is this expected?
>
> Why not?  Time values are known to produce bignums, yes.  

Ok.

> What does list-timers show on that system?

               1.0s         5.0s auto-revert-buffers
               5.4s            - undo-auto--boundary-timer
           4m 19.0s           5m persistent-scratch-save
   *           0.1s            t show-paren-function
   *           0.5s            t posframe-hidehandler-daemon-function
   *           0.5s            t #f(compiled-function () #<bytecode -0x181a979fe3c9ba30> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
   *           0.5s      :repeat blink-cursor-start
   *           1.0s            t which-key--update

Re: Question about bignum usage

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 20 Jun 2024 08:34:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why not?  Time values are known to produce bignums, yes.  
> 
> Ok.
> 
> > What does list-timers show on that system?
> 
>                1.0s         5.0s auto-revert-buffers
>                5.4s            - undo-auto--boundary-timer
>            4m 19.0s           5m persistent-scratch-save
>    *           0.1s            t show-paren-function
>    *           0.5s            t posframe-hidehandler-daemon-function
>    *           0.5s            t #f(compiled-function () #<bytecode -0x181a979fe3c9ba30> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
>    *           0.5s      :repeat blink-cursor-start
>    *           1.0s            t which-key--update

This means we check for expired times every 100 msec, so yes, we will
create a lot of bignums.  I see something similar here as well.

Re: Question about bignum usage

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 20 Jun 2024 08:34:22 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Why not?  Time values are known to produce bignums, yes.  
>> 
>> Ok.
>> 
>> > What does list-timers show on that system?
>> 
>>                1.0s         5.0s auto-revert-buffers
>>                5.4s            - undo-auto--boundary-timer
>>            4m 19.0s           5m persistent-scratch-save
>>    *           0.1s            t show-paren-function
>>    *           0.5s            t posframe-hidehandler-daemon-function
>>    *           0.5s            t #f(compiled-function () #<bytecode -0x181a979fe3c9ba30> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
>>    *           0.5s      :repeat blink-cursor-start
>>    *           1.0s            t which-key--update
>
> This means we check for expired times every 100 msec, so yes, we will
> create a lot of bignums.  I see something similar here as well.

Thanks.

It isn't a problem, one just have to know why it happens.

In igc, these bignums accumulate pretty quickly to figures like

  PVEC_BIGNUM                              97199         3110368

and much higher, where the first number is the number of bignums, and
the second is bytes. The number of fonts is also curious.

  PVEC_FONT                                90422        10868392

But all seem to be GC'd eventually.

Re: Question about bignum usage

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> the second is bytes. The number of fonts is also curious.
>
>   PVEC_FONT                                90422        10868392
>
> But all seem to be GC'd eventually.

FWIW, I'm attaching the Lisp that I currently use to display this stuff.
Something hacked together. M-x igc-stats displays a buffer in which one
can take two snapshots of igc-info, display them, sompare them, trigger
GC and so on.

The PVEC_FONT stuff is impressive :-) 


[-- Attachment #2: igc-stats.el --]
[-- Type: application/emacs-lisp, Size: 2983 bytes --]

Re: Question about bignum usage

[Helmut Eller]

On Thu, Jun 20 2024, Gerd Möllmann wrote:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> the second is bytes. The number of fonts is also curious.
>>
>>   PVEC_FONT                                90422        10868392
>>
>> But all seem to be GC'd eventually.
>
> FWIW, I'm attaching the Lisp that I currently use to display this stuff.
> Something hacked together. M-x igc-stats displays a buffer in which one
> can take two snapshots of igc-info, display them, sompare them, trigger
> GC and so on.

Thanks!  That's quite nice.

> The PVEC_FONT stuff is impressive :-) 

There don't seem to be so many PVEC_FONT objects here.  After
startup (with my normal .emacs):

PVEC_FONT                                 1251          151824

and then after opening igc.c and moving around a bit:

PVEC_FONT                                 1968          238312

Re: Question about bignum usage

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Thu, Jun 20 2024, Gerd Möllmann wrote:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> the second is bytes. The number of fonts is also curious.
>>>
>>>   PVEC_FONT                                90422        10868392
>>>
>>> But all seem to be GC'd eventually.
>>
>> FWIW, I'm attaching the Lisp that I currently use to display this stuff.
>> Something hacked together. M-x igc-stats displays a buffer in which one
>> can take two snapshots of igc-info, display them, sompare them, trigger
>> GC and so on.
>
> Thanks!  That's quite nice.
>
>> The PVEC_FONT stuff is impressive :-) 
>
> There don't seem to be so many PVEC_FONT objects here.  After
> startup (with my normal .emacs):
>
> PVEC_FONT                                 1251          151824
>
> and then after opening igc.c and moving around a bit:
>
> PVEC_FONT                                 1968          238312

That's interesting! I'm also using my normal init.el, so I'm just using
the igc branch in the way I use Emacs day by day. It's apparently not a
problem, but I wonder what's going on... 

Re: Question about bignum usage

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Thu, Jun 20 2024, Gerd Möllmann wrote:
>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>>> the second is bytes. The number of fonts is also curious.
>>>>
>>>>   PVEC_FONT                                90422        10868392
>>>>
>>>> But all seem to be GC'd eventually.
>>>
>>> FWIW, I'm attaching the Lisp that I currently use to display this stuff.
>>> Something hacked together. M-x igc-stats displays a buffer in which one
>>> can take two snapshots of igc-info, display them, sompare them, trigger
>>> GC and so on.
>>
>> Thanks!  That's quite nice.
>>
>>> The PVEC_FONT stuff is impressive :-) 
>>
>> There don't seem to be so many PVEC_FONT objects here.  After
>> startup (with my normal .emacs):
>>
>> PVEC_FONT                                 1251          151824
>>
>> and then after opening igc.c and moving around a bit:
>>
>> PVEC_FONT                                 1968          238312
>
> That's interesting! I'm also using my normal init.el, so I'm just using
> the igc branch in the way I use Emacs day by day. It's apparently not a
> problem, but I wonder what's going on... 

Seems to have something to do with a header line.

  * frame #0: 0x0000000100177d28 emacs`copy_font_spec [inlined] TAGGEDP(a=(struct font *) $1 = 0x000000010d749bb8, tag=Lisp_Vectorlike) at lisp.h:781:10 [opt]
    frame #1: 0x0000000100177d28 emacs`copy_font_spec [inlined] PSEUDOVECTORP(a=(struct font *) $2 = 0x000000010d749bb8, code=36) at lisp.h:1105:11 [opt]
    frame #2: 0x0000000100177d28 emacs`copy_font_spec [inlined] FONTP(x=(struct font *) $3 = 0x000000010d749bb8) at font.h:437:10 [opt]
    frame #3: 0x0000000100177d28 emacs`copy_font_spec [inlined] CHECK_FONT(x=(struct font *) $4 = 0x000000010d749bb8) at font.h:487:15 [opt]
    frame #4: 0x0000000100177d28 emacs`copy_font_spec(font=(struct font *) $5 = 0x000000010d749bb8) at font.c:4105:3 [opt]
!gud 4105:3:/Users/gerd/emacs/github/igc/src/font.c
    frame #5: 0x0000000100179898 emacs`font_clear_prop(attrs=(struct Lisp_Symbol *) $6 = 0x00000002706c9cf0, prop=FONT_WEIGHT_INDEX) at font.c:3088:12 [opt]
    frame #6: 0x00000001000c5c30 emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=(struct Lisp_Symbol *) $7 = 0x00000002706c97b8, to=(struct Lisp_Symbol *) $8 = 0x00000002706c9cf0, named_merge_points=<unavailable>) at xfaces.c:0 [opt]
    frame #7: 0x00000001000ccbcc emacs`merge_named_face(w=0x0000000106e41e28, f=0x0000000105c96c00, face_name=<unavailable>, to=(struct Lisp_Symbol *) $9 = 0x00000002706c9cf0, named_merge_points=<unavailable>, attr_filter=<no summary available>) at xfaces.c:2420:9 [opt]
    frame #8: 0x00000001000c93ec emacs`merge_face_ref(w=<unavailable>, f=0x0000000105c96c00, face_ref=(struct Lisp_Symbol *) $10 = 0x00000001008d7a60, to=(struct Lisp_Symbol *) $11 = 0x00000002706c9cf0, err_msgs=false, named_merge_points=0x000000016fdf6390, attr_filter=<no summary available>) at xfaces.c:2902:12 [opt]
    frame #9: 0x00000001000c5b70 emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=(struct Lisp_Symbol *) $12 = 0x00000002706c9a88, to=(struct Lisp_Symbol *) $13 = 0x00000002706c9cf0, named_merge_points=<unavailable>) at xfaces.c:2252:5 [opt]
    frame #10: 0x00000001000ccbcc emacs`merge_named_face(w=0x0000000106e41e28, f=0x0000000105c96c00, face_name=<unavailable>, to=(struct Lisp_Symbol *) $14 = 0x00000002706c9cf0, named_merge_points=<unavailable>, attr_filter=<no summary available>) at xfaces.c:2420:9 [opt]
    frame #11: 0x00000001000c93ec emacs`merge_face_ref(w=<unavailable>, f=0x0000000105c96c00, face_ref=(struct Lisp_Symbol *) $15 = 0x000000010adfa890, to=(struct Lisp_Symbol *) $16 = 0x00000002706c9cf0, err_msgs=true, named_merge_points=0x0000000000000000, attr_filter=<no summary available>) at xfaces.c:2902:12 [opt]
    frame #12: 0x00000001000cc564 emacs`face_at_string_position(w=0x0000000106e41e28, string=(struct Lisp_String *) $17 = 0x000000010adfd4a0, pos=1, bufpos=0, endptr=<unavailable>, base_face_id=<unavailable>, mouse_p=<unavailable>, attr_filter=<no summary available>) at xfaces.c:7044:5 [opt]
    frame #13: 0x00000001000376d4 emacs`display_string(string="*igc*", lisp_string=(struct Lisp_String *) $18 = 0x0000000106e3cf20, face_string=(struct Lisp_String *) $19 = 0x000000010adfd4a0, face_string_pos=1, start=<unavailable>, it=0x000000016fdf7e70, field_width=<unavailable>, precision=<unavailable>, max_x=0, multibyte=0) at xdisp.c:29122:4 [opt]
    frame #14: 0x0000000100030a38 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=-10, elt=(struct Lisp_String *) $20 = 0x000000010adfd4a0, props=(struct Lisp_Symbol *) $21 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27793:17 [opt]
    frame #15: 0x000000010002f4b8 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=-10, elt=<unavailable>, props=(struct Lisp_Symbol *) $22 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27970:13 [opt]
    frame #16: 0x000000010002f4b8 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=0, elt=<unavailable>, props=(struct Lisp_Symbol *) $23 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27970:13 [opt]
    frame #17: 0x000000010001dad4 emacs`display_mode_line(w=0x0000000106e41e28, face_id=MODE_LINE_ACTIVE_FACE_ID, format=(struct Lisp_Cons *) $24 = 0x000000010a267750) at xdisp.c:27395:7 [opt]
    frame #18: 0x0000000100052740 emacs`display_mode_lines(w=0x0000000106e41e28) at xdisp.c:27308:7 [opt]
    frame #19: 0x000000010005a5ac emacs`redisplay_window(window=(struct window *) $25 = 0x0000000106e41e28, just_this_one_p=false) at xdisp.c:20927:7 [opt]

It's always copy_font_spec that is involved in this way. I can lean on
'g' in the *igc* buffer, and watch is grow by the hundreds :-)

Re: Question about bignum usage

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Helmut Eller <eller.helmut@gmail.com> writes:
>>
>>> On Thu, Jun 20 2024, Gerd Möllmann wrote:
>>>
>>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>>
>>>>> the second is bytes. The number of fonts is also curious.
>>>>>
>>>>>   PVEC_FONT                                90422        10868392
>>>>>
>>>>> But all seem to be GC'd eventually.
>>>>
>>>> FWIW, I'm attaching the Lisp that I currently use to display this stuff.
>>>> Something hacked together. M-x igc-stats displays a buffer in which one
>>>> can take two snapshots of igc-info, display them, sompare them, trigger
>>>> GC and so on.
>>>
>>> Thanks!  That's quite nice.
>>>
>>>> The PVEC_FONT stuff is impressive :-) 
>>>
>>> There don't seem to be so many PVEC_FONT objects here.  After
>>> startup (with my normal .emacs):
>>>
>>> PVEC_FONT                                 1251          151824
>>>
>>> and then after opening igc.c and moving around a bit:
>>>
>>> PVEC_FONT                                 1968          238312
>>
>> That's interesting! I'm also using my normal init.el, so I'm just using
>> the igc branch in the way I use Emacs day by day. It's apparently not a
>> problem, but I wonder what's going on... 
>
> Seems to have something to do with a header line.
>
>   * frame #0: 0x0000000100177d28 emacs`copy_font_spec [inlined] TAGGEDP(a=(struct font *) $1 = 0x000000010d749bb8, tag=Lisp_Vectorlike) at lisp.h:781:10 [opt]
>     frame #1: 0x0000000100177d28 emacs`copy_font_spec [inlined] PSEUDOVECTORP(a=(struct font *) $2 = 0x000000010d749bb8, code=36) at lisp.h:1105:11 [opt]
>     frame #2: 0x0000000100177d28 emacs`copy_font_spec [inlined] FONTP(x=(struct font *) $3 = 0x000000010d749bb8) at font.h:437:10 [opt]
>     frame #3: 0x0000000100177d28 emacs`copy_font_spec [inlined] CHECK_FONT(x=(struct font *) $4 = 0x000000010d749bb8) at font.h:487:15 [opt]
>     frame #4: 0x0000000100177d28 emacs`copy_font_spec(font=(struct font *) $5 = 0x000000010d749bb8) at font.c:4105:3 [opt]
> !gud 4105:3:/Users/gerd/emacs/github/igc/src/font.c
>     frame #5: 0x0000000100179898 emacs`font_clear_prop(attrs=(struct Lisp_Symbol *) $6 = 0x00000002706c9cf0, prop=FONT_WEIGHT_INDEX) at font.c:3088:12 [opt]
>     frame #6: 0x00000001000c5c30 emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=(struct Lisp_Symbol *) $7 = 0x00000002706c97b8, to=(struct Lisp_Symbol *) $8 = 0x00000002706c9cf0, named_merge_points=<unavailable>) at xfaces.c:0 [opt]
>     frame #7: 0x00000001000ccbcc emacs`merge_named_face(w=0x0000000106e41e28, f=0x0000000105c96c00, face_name=<unavailable>, to=(struct Lisp_Symbol *) $9 = 0x00000002706c9cf0, named_merge_points=<unavailable>, attr_filter=<no summary available>) at xfaces.c:2420:9 [opt]
>     frame #8: 0x00000001000c93ec emacs`merge_face_ref(w=<unavailable>, f=0x0000000105c96c00, face_ref=(struct Lisp_Symbol *) $10 = 0x00000001008d7a60, to=(struct Lisp_Symbol *) $11 = 0x00000002706c9cf0, err_msgs=false, named_merge_points=0x000000016fdf6390, attr_filter=<no summary available>) at xfaces.c:2902:12 [opt]
>     frame #9: 0x00000001000c5b70 emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=(struct Lisp_Symbol *) $12 = 0x00000002706c9a88, to=(struct Lisp_Symbol *) $13 = 0x00000002706c9cf0, named_merge_points=<unavailable>) at xfaces.c:2252:5 [opt]
>     frame #10: 0x00000001000ccbcc emacs`merge_named_face(w=0x0000000106e41e28, f=0x0000000105c96c00, face_name=<unavailable>, to=(struct Lisp_Symbol *) $14 = 0x00000002706c9cf0, named_merge_points=<unavailable>, attr_filter=<no summary available>) at xfaces.c:2420:9 [opt]
>     frame #11: 0x00000001000c93ec emacs`merge_face_ref(w=<unavailable>, f=0x0000000105c96c00, face_ref=(struct Lisp_Symbol *) $15 = 0x000000010adfa890, to=(struct Lisp_Symbol *) $16 = 0x00000002706c9cf0, err_msgs=true, named_merge_points=0x0000000000000000, attr_filter=<no summary available>) at xfaces.c:2902:12 [opt]
>     frame #12: 0x00000001000cc564 emacs`face_at_string_position(w=0x0000000106e41e28, string=(struct Lisp_String *) $17 = 0x000000010adfd4a0, pos=1, bufpos=0, endptr=<unavailable>, base_face_id=<unavailable>, mouse_p=<unavailable>, attr_filter=<no summary available>) at xfaces.c:7044:5 [opt]
>     frame #13: 0x00000001000376d4 emacs`display_string(string="*igc*", lisp_string=(struct Lisp_String *) $18 = 0x0000000106e3cf20, face_string=(struct Lisp_String *) $19 = 0x000000010adfd4a0, face_string_pos=1, start=<unavailable>, it=0x000000016fdf7e70, field_width=<unavailable>, precision=<unavailable>, max_x=0, multibyte=0) at xdisp.c:29122:4 [opt]
>     frame #14: 0x0000000100030a38 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=-10, elt=(struct Lisp_String *) $20 = 0x000000010adfd4a0, props=(struct Lisp_Symbol *) $21 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27793:17 [opt]
>     frame #15: 0x000000010002f4b8 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=-10, elt=<unavailable>, props=(struct Lisp_Symbol *) $22 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27970:13 [opt]
>     frame #16: 0x000000010002f4b8 emacs`display_mode_element(it=0x000000016fdf7e70, depth=<unavailable>, field_width=0, precision=0, elt=<unavailable>, props=(struct Lisp_Symbol *) $23 = 0x00000001008d36e0, risky=<unavailable>) at xdisp.c:27970:13 [opt]
>     frame #17: 0x000000010001dad4 emacs`display_mode_line(w=0x0000000106e41e28, face_id=MODE_LINE_ACTIVE_FACE_ID, format=(struct Lisp_Cons *) $24 = 0x000000010a267750) at xdisp.c:27395:7 [opt]
>     frame #18: 0x0000000100052740 emacs`display_mode_lines(w=0x0000000106e41e28) at xdisp.c:27308:7 [opt]
>     frame #19: 0x000000010005a5ac emacs`redisplay_window(window=(struct window *) $25 = 0x0000000106e41e28, just_this_one_p=false) at xdisp.c:20927:7 [opt]
>
> It's always copy_font_spec that is involved in this way. I can lean on
> 'g' in the *igc* buffer, and watch is grow by the hundreds :-)

Maybe it's my use of modus-themes. But whatever, enough played :-)

  Face: header-line (sample) (customize this face)

  Documentation:
  Basic header-line face.

  Defined in ‘faces.el’.


             Family: unspecified
            Foundry: unspecified
              Width: unspecified
             Height: unspecified
             Weight: unspecified
              Slant: unspecified
         Foreground: unspecified
  DistantForeground: unspecified
         Background: #1e1e1e
          Underline: unspecified
           Overline: unspecified
     Strike-through: unspecified
                Box: unspecified
            Inverse: unspecified
            Stipple: unspecified
               Font: unspecified
            Fontset: unspecified
             Extend: unspecified
            Inherit: modus-themes-ui-variable-pitch

    This face was introduced, or its default value was changed, in
    version 21.1 of Emacs.

Re: Question about bignum usage

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 20 Jun 2024 20:32:00 +0200
> 
> Seems to have something to do with a header line.

You mean, mode line, right?  Because:

>     frame #17: 0x000000010001dad4 emacs`display_mode_line(w=0x0000000106e41e28, face_id=MODE_LINE_ACTIVE_FACE_ID, format=(struct Lisp_Cons *) $24 = 0x000000010a267750) at xdisp.c:27395:7 [opt]

MODE_LINE_ACTIVE_FACE_ID is for the mode line, not for the header
line.

> It's always copy_font_spec that is involved in this way. I can lean on
> 'g' in the *igc* buffer, and watch is grow by the hundreds :-)

Does the "*igc*" string have face or mouse-face text properties?  If
not, I don't understand why face_at_string_position calls
merge_face_ref.

Re: Question about bignum usage

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Thu, 20 Jun 2024 20:32:00 +0200
>> 
>> Seems to have something to do with a header line.
>
> You mean, mode line, right?  Because:
>
>>     frame #17: 0x000000010001dad4 emacs`display_mode_line(w=0x0000000106e41e28, face_id=MODE_LINE_ACTIVE_FACE_ID, format=(struct Lisp_Cons *) $24 = 0x000000010a267750) at xdisp.c:27395:7 [opt]
>
> MODE_LINE_ACTIVE_FACE_ID is for the mode line, not for the header
> line.
>
>> It's always copy_font_spec that is involved in this way. I can lean on
>> 'g' in the *igc* buffer, and watch is grow by the hundreds :-)
>
> Does the "*igc*" string have face or mouse-face text properties?  If
> not, I don't understand why face_at_string_position calls
> merge_face_ref.

Oh right, I've overlooked the id, sorry.

The "*igc*" is the buffer name. It doesn't have properties that I put on
it. And the mode-line face looks almost like the header-line face,
except the colors.

  Face: mode-line (sample) (customize this face)

  Documentation:
  Face for the mode lines as well as header lines.
  See ‘mode-line-active’ and ‘mode-line-inactive’ for the faces
  used on mode lines.

  Defined in ‘faces.el’.


             Family: unspecified
            Foundry: unspecified
              Width: unspecified
             Height: unspecified
             Weight: unspecified
              Slant: unspecified
         Foreground: #ffffff
  DistantForeground: unspecified
         Background: #505050
          Underline: unspecified
           Overline: unspecified
     Strike-through: unspecified
                Box: #959595
            Inverse: unspecified
            Stipple: unspecified
               Font: unspecified
            Fontset: unspecified
             Extend: unspecified
            Inherit: modus-themes-ui-variable-pitch

    This face was introduced, or its default value was changed, in
    version 21.1 of Emacs.

  [back]

Re: Question about bignum usage

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 20 Jun 2024 21:16:40 +0200
> 
> The "*igc*" is the buffer name. It doesn't have properties that I put on
> it.

If it's the buffer name, then mode-line-format puts the mouse-face on
it, to make it mouse-sensitive.  Which probably explains why we call
merge_face_ref.

Re: Question about bignum usage

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 20 Jun 2024 21:16:40 +0200
>> 
>> The "*igc*" is the buffer name. It doesn't have properties that I put on
>> it.
>
> If it's the buffer name, then mode-line-format puts the mouse-face on
> it, to make it mouse-sensitive.  Which probably explains why we call
> merge_face_ref.

That makes sense, thanks!

Re: Question about bignum usage

[Mattias Engdegård]

20 juni 2024 kl. 09.36 skrev Eli Zaretskii <eliz@gnu.org>:

> This means we check for expired times every 100 msec, so yes, we will
> create a lot of bignums.

Right, and a few hundred bignums allocated every second isn't something even the current GC should have any trouble with.

But it is a bit wasteful, isn't it? We use very short-lived bignums for internal purposes even when the picosecond part is 0, in places like decode_timer where there should be need to cons anything at all.

Re: Question about bignum usage

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Thu, 20 Jun 2024 11:38:48 +0200
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  emacs-devel@gnu.org
> 
> 20 juni 2024 kl. 09.36 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > This means we check for expired times every 100 msec, so yes, we will
> > create a lot of bignums.
> 
> Right, and a few hundred bignums allocated every second isn't something even the current GC should have any trouble with.
> 
> But it is a bit wasteful, isn't it? We use very short-lived bignums for internal purposes even when the picosecond part is 0, in places like decode_timer where there should be need to cons anything at all.

Sure, if that can be avoided, it would be beneficial.  Paul, any
suggestions?