[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67536: 29.1; Calc mode's math-read-preprocess-string conses unnecess
From: |
Eli Zaretskii |
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@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.