[Top][All Lists]

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

Re: Convert README.org to plain text README while installing package

From: Ihor Radchenko
Subject: Re: Convert README.org to plain text README while installing package
Date: Wed, 08 Jun 2022 23:44:38 +0800

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Which, btw, yet another problem: why does loading Org produce so much
>>> garbage?  Can this be kept in check somehow?
>> AFAIU, so much garbage is produced simply because nobody looked into
>> memory usage. It is not the easiest thing to track in Emacs.
>> Can it be kept in check? Maybe. We need to identify first which parts
>> are taking excess memory. org-link-set-parameters appears to be one of
>> the bottlenecks. I do not know any others.
> w.r.t spending time in the GC, since the GC is run based on the amount
> of memory that has been allocated (as opposed to the amount of garbage
> generated, for example. which we sadly can't know in advance), the "mem"
> profiler (aka `M-x profilter-start RET mem RET`) can be very useful
> since it does a sampling-based profiling where the "time" is measured in
> number of byte allocated (or some approximation thereof).

I know the 'mem profiler. It can help in some cases. That's how I
noticed org-link-set-parameter.

However, here is one recent memory profiler report:

  1,307,745,624  23%                            - org-persist-load
  1,307,726,070  23%                             - org-persist-read
  1,281,385,671  22%                              - seq-find
  1,281,385,671  22%                               - seq-do
  1,281,385,671  22%                                - mapc
  1,281,385,671  22%                                 - #<compiled 
  1,281,385,671  22%                                  - #<compiled 
  1,281,385,671  22%                                   - 
        333,712   0%                                    + 

Unless I misinterpret things, run-hook-with-args-until-success is
allocating memory. However, that hook contains a single function which
is not allocating much according to the profiler.

Moreover, I know myself that the actual memory allocation is done down
in org-perist-read when running (read (current-buffer)). I got memory
profiler wrong significant amount of time to learn not to trust it too

cpu profiler is a bit more robust in this regard. At least not until I
C-g in the middle of the profiling.


reply via email to

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