From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Fri, 23 Mar 2018 10:39:04 -0400 Message-ID: References: <834lldp18f.fsf@gnu.org> <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de> <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> <83vadso9ad.fsf@gnu.org> <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> <1ea4248a-11ce-00a9-0644-df7b2e5a3a58@arkona-technologies.de> <838tajhsau.fsf@gnu.org> <837eq2j2i5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521815855 21122 195.159.176.226 (23 Mar 2018 14:37:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 14:37:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 15:37:31 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ezNow-0005ME-GL for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 15:37:30 +0100 Original-Received: from localhost ([::1]:38390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezNqz-0001qF-Np for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 10:39:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezNqh-0001n3-QR for emacs-devel@gnu.org; Fri, 23 Mar 2018 10:39:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezNqd-00060L-SN for emacs-devel@gnu.org; Fri, 23 Mar 2018 10:39:19 -0400 Original-Received: from [195.159.176.226] (port=57910 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ezNqd-0005zc-Jm for emacs-devel@gnu.org; Fri, 23 Mar 2018 10:39:15 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ezNoX-0004sL-DJ for emacs-devel@gnu.org; Fri, 23 Mar 2018 15:37:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 25 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:9Z/lOlRQl+ZUCZc7pwqRv3Wkbmc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223966 Archived-At: >> > I'd be interested to see a comparison with a code that ignores the >> > markers entirely, and uses just these 4: >> > CONSIDER (BUF_PT (b), BUF_PT_BYTE (b)); >> > CONSIDER (BUF_GPT (b), BUF_GPT_BYTE (b)); >> > CONSIDER (BUF_BEGV (b), BUF_BEGV_BYTE (b)); >> > CONSIDER (BUF_ZV (b), BUF_ZV_BYTE (b)); >> I tried that, and in the synthetic benchmark which tries to reproduce >> Sebastian's lsp-mode situation the result was indeed much better, but >> then in other benchmarks it caused very significant slowdowns. > In what benchmarks did it cause significant slowdowns? Can't remember exactly, I think it was bad enough for a test case which seemed pretty realistic so I discarded that option. Basically what I remember is that I got the impression that it would probably harm more users than the problem at hand. Stefan PS: BTW, the number of markers is not the only issue: the order in which they are created also matters. Maybe we should try Sebastian's test case but creating the markers/overlays in random order (and if that helps, we could get a similar effect by making the GC randomly shuffle the buffers's list of markers ;-).