From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Thu, 06 Jul 2023 20:50:00 +0300 Message-ID: <83mt09gcaf.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org> <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org> <87o7kpxapo.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31384"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 06 19:50:47 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHT7u-0007xu-Dh for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 19:50:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHT7D-0003o3-In; Thu, 06 Jul 2023 13:50:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHT7C-0003nX-Eh for emacs-devel@gnu.org; Thu, 06 Jul 2023 13:50:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHT7C-0002wj-02; Thu, 06 Jul 2023 13:50:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FJ5aG5bwl5M8fUz7AMoC2gYqt1V3DAYdQoug61rE9qE=; b=CpIK9jsS+gi2 Bxu8ELPm6SwnrLE+gg2VCryo9yqEl5rjP25uyApRb0oxBE1k9OB5dc3NC7HTuRcEjE/187ZmavGUE alacXCku0jskZGR36vd8Nis8ZkderL7zH6Q/cZpJsi5XPQMqKX3ZwLEe2PMuHtNpzS34VEZV6mkAX V+GpG+qRg5g8GP8VuvLJdCEwdfwEOzSbkmj8vyif0kspzGKqk9nvmS2FSp462BBntZITUnEZ6C3i6 0J9DedLgZX2FGFhWgzMLiARAD5A+Bhev72RlFvwECtCa99EpXI3kiOqrMvRWbIoospr8hEhpx3Sfp /CHOeO9EE6i259Hzr6FN/g==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHT7B-0007Gd-Fs; Thu, 06 Jul 2023 13:50:01 -0400 In-Reply-To: <87o7kpxapo.fsf@localhost> (message from Ihor Radchenko on Thu, 06 Jul 2023 16:32:03 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307524 Archived-At: > From: Ihor Radchenko > 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.