Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Thu, 06 Jul 2023 16:32:03 +0000
> 
> > 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.

Once again, it isn't necessarily memory allocation per se.  For
example, it could be find_suspicious_object_in_range, called from
allocate_vectorlike.

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

I very much doubt these interrupts are because Emacs waits for memory
allocation.

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

Aren't we talking precisely about several threads running
concurrently?

> If a thread is working with a temporary buffer and locks it, that
> buffer has almost 0 chance to be accessed by another thread.

But "working on a buffer" requires access and modification of many
global structures.  Just walk the code in set-buffer and its
subroutines, and you will see that.

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

I think you misunderstand the frequency of such collisions.
case-fold-search comes to mind.