* Question about bignum usage
@ 2024-06-20 5:59 Gerd Möllmann
2024-06-20 6:26 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 5:59 UTC (permalink / raw)
To: Emacs Devel
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 5:59 Question about bignum usage Gerd Möllmann
@ 2024-06-20 6:26 ` Eli Zaretskii
2024-06-20 6:34 ` Gerd Möllmann
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2024-06-20 6:26 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 6:26 ` Eli Zaretskii
@ 2024-06-20 6:34 ` Gerd Möllmann
2024-06-20 7:36 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 6:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 6:34 ` Gerd Möllmann
@ 2024-06-20 7:36 ` Eli Zaretskii
2024-06-20 8:35 ` Gerd Möllmann
2024-06-20 9:38 ` Mattias Engdegård
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2024-06-20 7:36 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 7:36 ` Eli Zaretskii
@ 2024-06-20 8:35 ` Gerd Möllmann
2024-06-20 13:07 ` Gerd Möllmann
2024-06-20 9:38 ` Mattias Engdegård
1 sibling, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 8:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 7:36 ` Eli Zaretskii
2024-06-20 8:35 ` Gerd Möllmann
@ 2024-06-20 9:38 ` Mattias Engdegård
2024-06-20 10:02 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2024-06-20 9:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gerd Möllmann, emacs-devel
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 9:38 ` Mattias Engdegård
@ 2024-06-20 10:02 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2024-06-20 10:02 UTC (permalink / raw)
To: Mattias Engdegård, Paul Eggert; +Cc: gerd.moellmann, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 8:35 ` Gerd Möllmann
@ 2024-06-20 13:07 ` Gerd Möllmann
2024-06-20 13:43 ` Helmut Eller
0 siblings, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 13:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Helmut Eller
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 13:07 ` Gerd Möllmann
@ 2024-06-20 13:43 ` Helmut Eller
2024-06-20 14:17 ` Gerd Möllmann
0 siblings, 1 reply; 16+ messages in thread
From: Helmut Eller @ 2024-06-20 13:43 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 13:43 ` Helmut Eller
@ 2024-06-20 14:17 ` Gerd Möllmann
2024-06-20 18:32 ` Gerd Möllmann
0 siblings, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 14:17 UTC (permalink / raw)
To: Helmut Eller; +Cc: Eli Zaretskii, emacs-devel
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...
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 14:17 ` Gerd Möllmann
@ 2024-06-20 18:32 ` Gerd Möllmann
2024-06-20 18:37 ` Gerd Möllmann
2024-06-20 18:58 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 18:32 UTC (permalink / raw)
To: Helmut Eller; +Cc: Eli Zaretskii, emacs-devel
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 :-)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 18:32 ` Gerd Möllmann
@ 2024-06-20 18:37 ` Gerd Möllmann
2024-06-20 18:58 ` Eli Zaretskii
1 sibling, 0 replies; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 18:37 UTC (permalink / raw)
To: Helmut Eller; +Cc: Eli Zaretskii, emacs-devel
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 18:32 ` Gerd Möllmann
2024-06-20 18:37 ` Gerd Möllmann
@ 2024-06-20 18:58 ` Eli Zaretskii
2024-06-20 19:16 ` Gerd Möllmann
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2024-06-20 18:58 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: eller.helmut, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 18:58 ` Eli Zaretskii
@ 2024-06-20 19:16 ` Gerd Möllmann
2024-06-20 19:25 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 19:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eller.helmut, emacs-devel
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]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 19:16 ` Gerd Möllmann
@ 2024-06-20 19:25 ` Eli Zaretskii
2024-06-20 19:42 ` Gerd Möllmann
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2024-06-20 19:25 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: eller.helmut, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about bignum usage
2024-06-20 19:25 ` Eli Zaretskii
@ 2024-06-20 19:42 ` Gerd Möllmann
0 siblings, 0 replies; 16+ messages in thread
From: Gerd Möllmann @ 2024-06-20 19:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eller.helmut, emacs-devel
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!
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-06-20 19:42 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-20 5:59 Question about bignum usage Gerd Möllmann
2024-06-20 6:26 ` Eli Zaretskii
2024-06-20 6:34 ` Gerd Möllmann
2024-06-20 7:36 ` Eli Zaretskii
2024-06-20 8:35 ` Gerd Möllmann
2024-06-20 13:07 ` Gerd Möllmann
2024-06-20 13:43 ` Helmut Eller
2024-06-20 14:17 ` Gerd Möllmann
2024-06-20 18:32 ` Gerd Möllmann
2024-06-20 18:37 ` Gerd Möllmann
2024-06-20 18:58 ` Eli Zaretskii
2024-06-20 19:16 ` Gerd Möllmann
2024-06-20 19:25 ` Eli Zaretskii
2024-06-20 19:42 ` Gerd Möllmann
2024-06-20 9:38 ` Mattias Engdegård
2024-06-20 10:02 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).