* 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 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
* 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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.