[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency via isolated process/thread
From: |
Ihor Radchenko |
Subject: |
Re: Concurrency via isolated process/thread |
Date: |
Fri, 07 Jul 2023 12:30:16 +0000 |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
I did not have ENABLE_CHECKING in this benchmark.
It is just ./configure --with-native-compilation
So, find_suspicious_object_in_range should not run at all.
>> 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.
I guess we can be optimistic. And if not, maybe need to have multiple heaps.
>> 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.
I was only able to identify the following:
interrupt_input_blocked
current_buffer
last_known_column_point
AFAIU, current_buffer might be made thread-local and
last_known_column_point can be made buffer-local.
interrupt_input_blocked is more tricky. But it is just one global state
variable. Surely we can find a solution to make it work with multiple threads.
>> 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.
How so? What is the problem with a buffer-local variable that is rarely
set directly (other than by major modes)? let-binding is common, but it
is not a problem.
--
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>
- Re: Concurrency via isolated process/thread, (continued)
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/06
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/06
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/06
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/06
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/06
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/06
- Re: Concurrency via isolated process/thread,
Ihor Radchenko <=
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/07
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/07
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/07
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/07
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/08
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/08
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/08
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/09
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/09
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/09