info-gnus-english
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

slow saving of scores when leaving a virtual (nnml+) group


From: Eric S Fraga
Subject: slow saving of scores when leaving a virtual (nnml+) group
Date: Thu, 06 Jul 2023 12:45:00 +0100
User-agent: gnus (Emacs 30.0.50)

Hello all,

recently (past week or two), I've noticed a slow down in leaving some of
my nnml groups.  Using the profiler, I see the outcomes shown below,
capturing cpu and memory when entering a virtual group, that collects 3
different nnml groups, and then immediately leaving that group.  A
significant amount of time is taken saving scores, as far as I can tell.
I use adaptive scoring.  Nothing with respect to scoring has changed in
my configuration in some time (years probably).

The offending function appears to be "lisp--local-defform-body-p" with
large memory and cpu use.

Cpu report (partly expanded):

       10133  79% - command-execute
        8519  66%  - funcall-interactively
        4767  37%   - gnus-summary-exit
        4659  36%    - gnus-score-save
        4655  36%     - gnus-pp
        4655  36%      - pp
        4655  36%       - pp-to-string
        4655  36%        - pp-fill
        4647  36%         - pp--object
        4627  36%          - pp-fill
        4615  36%           - pp-fill
        4555  35%            - pp-fill
        4263  33%             - pp-fill
        4243  33%              - indent-according-to-mode
        4243  33%               - lisp-indent-line
        4163  32%                - calculate-lisp-indent
        4163  32%                 - lisp-indent-function
        4163  32%                    lisp--local-defform-body-p
          48   0%                + lisp-ppss
         240   1%             + indent-according-to-mode
          72   0%    + gnus-run-hooks
          32   0%    + gnus-close-group
           4   0%    + gnus-summary-update-info
        3688  28%   + gnus-topic-select-group
          60   0%   + file-notify-handle-event
           3   0%   + execute-extended-command
        1614  12%  + byte-code
        2260  17%   Automatic GC
         407   3% + timer-event-handler
           0   0%   ...

and memory report, also partly expanded:

    832,940,181  99% - command-execute
    805,535,710  96%  - funcall-interactively
    540,874,166  64%   - gnus-summary-exit
    537,712,423  64%    - gnus-score-save
    536,634,533  64%     - gnus-pp
    535,956,310  64%      - pp
    535,618,670  64%       - pp-to-string
    535,610,465  64%        - pp-fill
    533,695,189  63%         - pp--object
    533,684,957  63%          - pp-fill
    533,683,933  63%           - pp-fill
    533,651,141  63%            - pp-fill
    532,169,752  63%             - pp-fill
    531,888,880  63%              - indent-according-to-mode
    531,888,880  63%               - lisp-indent-line
    484,726,608  58%                - calculate-lisp-indent
    484,661,024  58%                 - lisp-indent-function
    484,661,024  58%                    lisp--local-defform-body-p
        902,445   0%             + indent-according-to-mode
             21   0%       nnheader-set-temp-buffer
      1,609,314   0%    + gnus-summary-update-info
        924,174   0%    + gnus-close-group
        579,308   0%    + gnus-run-hooks
          2,069   0%      gnus-score-adaptive
          1,529   0%    + gnus-configure-windows
             21   0%      gnus-set-global-variables
    263,358,645  31%   + gnus-topic-select-group
        839,207   0%   + execute-extended-command
        463,692   0%   + file-notify-handle-event
     27,404,471   3%  + byte-code
        983,687   0% + timer-event-handler
         53,056   0% + redisplay_internal (C function)
         14,903   0%   Automatic GC
          6,224   0% + hl-line-highlight
             21   0%   gnus-set-global-variables
              0   0%   ...

Any suggestions on how to improve the performance?  Or is it something I
may have done inadvertently?

Thank you,
eric

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]