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 15:01:39 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I may be wrong, but from my previous experience with performance
> >> benchmarks, memory allocation often takes a significant fraction of CPU
> >> time. And memory allocation is a routine process on pretty much every
> >> iteration of CPU-intensive code.
> >
> > Do you have any evidence for that which you can share?  GC indeed
> > takes significant time, but memory allocation? never heard of that.
> 
> This is from my testing of Org parser.
> I noticed that storing a pair of buffer positions is noticeably faster
> compared to storing string copies of buffer text.
> 
> The details usually do not show up in M-x profiler reports, but I now
> tried perf out of curiosity:
> 
>     14.76%  emacs         emacs                                  [.] 
> re_match_2_internal
>      9.39%  emacs         emacs                                  [.] 
> re_compile_pattern
>      4.45%  emacs         emacs                                  [.] 
> re_search_2
>      3.98%  emacs         emacs                                  [.] 
> funcall_subr
> 
>      
>      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.

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

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

> Locking specific Lisp objects is unlikely to lock normal Emacs usage,
> especially when the async code is written carefully. Except when there
> is a need to lock something from global and frequently used Emacs state,
> like heap or obarray. Which is why I asked about memory allocation.

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