Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>>      AFAIU, this is memory allocation. Taking a good one second in this case.
>>      3.37%  emacs         emacs                                  [.] 
>> allocate_vectorlike
>
> It is?  Which part(s) of allocate_vectorlike take these 3.37% of run
> time?  It does much more than just allocate memory.

Sorry, but I have no idea. The above is what I see from perf report.

For comparison, this is how things look like with Org parser version
that allocated 1.5-2x more memory (proper strings instead of buffer
positions and proper strings instead of interned constant strings):

    18.39%  emacs         emacs                           [.] exec_byte_code
    13.80%  emacs         emacs                           [.] 
re_match_2_internal
     6.56%  emacs         emacs                           [.] re_compile_pattern

     5.09%  emacs         emacs                           [.] 
allocate_vectorlike

     4.35%  emacs         emacs                           [.] re_search_2
     3.57%  emacs         emacs                           [.] Fmemq
     3.13%  emacs         emacs                           [.] find_interval

So, my efforts did reduce the time spent in allocate_vectorlike.
Note, however, that these two datapoints differ more than just by how
memory is allocated.

But 5% CPU time spend allocating memory is not insignificant.

>> These are just CPU cycles. I am not sure if there are any other
>> overheads related to memory allocation that translate into extra user time. 
>
> Well, we need to be pretty damn sure before we consider this a fact,
> don't we?

Sure. Though my argument was less about how long Emacs spends allocating
memory and more about how frequently a typical Elisp code requests such
allocations. I have a gut feeling that even if taking short time,
frequent interrupts may create intermittent typing delays.

>> > ... But the global lock used by the Lisp threads we have is actually
>> > such a lock, and the results are well known.
>> 
>> To be fair, global lock is an extreme worst-case scenario.
>
> If you consider the fact that the global state in Emacs is huge, maybe
> it is a good approximation to what will need to be locked anyway?

Not every thread will need to use global state, except maybe memory
allocation. Or do I miss an elephant in the room?

> You forget buffers, windows, frames, variables, and other global stuff.

Those will only matter when we try to access them from multiple threads,
no? If a thread is working with a temporary buffer and locks it, that
buffer has almost 0 chance to be accessed by another thread.
Same with variables - even if some global variable needs to be locked,
it is unlikely that it will need to be accessed by another thread.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>