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

[Ihor Radchenko]

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 
0x43febaeb8a58606>
  1,281,385,671  22%                                  - #<compiled 
-0x148951e07c95fd1a>
  1,281,385,671  22%                                   - 
run-hook-with-args-until-success
        333,712   0%                                    + 
org-element--cache-persist-before-read

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
much.

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

Best,
Ihor