GNU bug report logs - #67536
29.1; Calc mode's math-read-preprocess-string conses unnecessarily

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: 67536 <at> debbugs.gnu.org
Subject: bug#67536: 29.1; Calc mode's math-read-preprocess-string conses unnecessarily
Date: Thu, 30 Nov 2023 09:00:18 +0200

> From: Raffael Stocker <r.stocker <at> mnet-mail.de>
> Date: Wed, 29 Nov 2023 22:29:38 +0100
> 
> 
> Org table re-calculation is very slow, partly due to
> math-read-preprocess-string of calc mode consing unnecessarily.  For
> example, in one (large) table, I get the following memory usage from the
> profiler:
> 
> ...
>      60,252,646  96%   - org-ctrl-c-ctrl-c
>      60,248,166  96%    - org-table-calc-current-TBLFM
>      60,216,431  96%     - funcall-interactively
>      60,205,119  96%      - org-table-recalculate
>      49,094,651  78%       - org-table-eval-formula
>      32,624,631  52%        - calc-eval
>      32,624,631  52%         - calc-do-calc-eval
>      32,620,487  52%          - calc-do-calc-eval
>      32,611,151  52%           - math-read-exprs
>      29,388,838  47%            + math-read-preprocess-string
>       2,343,257   3%            + math-read-expr-list

This is not memory usage, this is CPU usage measured by using
memory-allocation functions as triggers to probe for the function that
is being executed.  So its evidence about consing and GC pressure is
indirect at best.

Can you instead look at the values of gcs-done and gc-elapsed before
and after running the offending code, and show the delta of each one
of them, with and without your proposed changes?  Then we will see a
much more direct evidence about the number of GC cycles and the time
spent in GC, and could make the decision about how to improve the
situation.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.