From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id uLE9DWffLWPKUQAAbAwnHQ (envelope-from ) for ; Fri, 23 Sep 2022 18:31:35 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id yKFhDGffLWP7uQAAG6o9tA (envelope-from ) for ; Fri, 23 Sep 2022 18:31:35 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DCD2E10404 for ; Fri, 23 Sep 2022 18:31:34 +0200 (CEST) Received: from localhost ([::1]:48356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oblaP-0004tu-Tj for larch@yhetil.org; Fri, 23 Sep 2022 12:31:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oblRK-0005Gi-EM for emacs-orgmode@gnu.org; Fri, 23 Sep 2022 12:22:11 -0400 Received: from ciao.gmane.io ([116.202.254.214]:34224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oblRI-0006wJ-QV for emacs-orgmode@gnu.org; Fri, 23 Sep 2022 12:22:10 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oblRE-0001OM-Ku for emacs-orgmode@gnu.org; Fri, 23 Sep 2022 18:22:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: line-number-at-pos performance and cache-long-scans Date: Fri, 23 Sep 2022 23:21:54 +0700 Message-ID: References: <87edw9z81n.fsf@tec.tecosaur.net> <87pmfn99fc.fsf@tec.tecosaur.net> <87v8pe96dm.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US In-Reply-To: <87v8pe96dm.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663950694; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=dDgj+5NqbHL4eMkRW1socjP6Vy/op6Q8jESXcOvKOHo=; b=qRbta/z/GXBjFzENdYVJiFkpM529pgU+aFC1qTI919ZUU3OIgtEicCYVGecA8CNApOLu2K XjWR1fAQaxhDn0ZWBW1Mfx9rC+saiQbnScjNL67eaZuN9KrV0YGoh1yVqvjIr+liKXt5Jk EswW2sbCJ4eIHD3Aux0Vw+SAHzCGpxUzCG/GFFr0Xng9SbM/+r3GwZLVdUqfrNeW7jfbwS CUT9SwEVDd7OAJM3JERAsWJEYjZM9jaNCwtO6XGcDpCuXZewTvyvZbeNjihz5dQLTLFKcy PvyX33HQeBeKFA3m+hTCBVOeom8ZtddQGUT67dpcs5OrQOONnphYRfYZDXEnvA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663950694; a=rsa-sha256; cv=none; b=V72T40p9gtfw0N7SpXaonm7DoHe/BG4xblLEI1j7kXnLCdJFAXRG+P1Koh4iNpPbflMA6o QEPxCNrXZNTRYs8Nj+la04rmPZ+T/Jv2ISmG8GwVwQ+8QZZnci0XyZxmaSgaeNDHe3fDJP LH+jpuUDln4skhUQEUTTdudSsDg1VZBXMjG74Tk4m1ASvo9MpaskheASOZGCqVT+PpRnya ldfcsLwIHcac/ObcbxuBl0nd5ij0/P4Rl8MpJTWebJt8Q5MO3utfEHDF4RhdB4ta8+8TAL oGEFOjvAL3iF07uBBz/75fDBM0GpHNybzLrCxvbwPfL0+NFJO6ZF/VSC259tvw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 2.85 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: DCD2E10404 X-Spam-Score: 2.85 X-Migadu-Scanner: scn1.migadu.com X-TUID: rjyZq5QrOtvE On 23/09/2022 09:22, Ihor Radchenko wrote: > Max Nikulin writes: > >> Despite improvements since Emacs-26 in line counting, still I believe >> that the `line-number-at-pos' function may still be excessively >> expensive in real live when unconditionally used just for a bit nicer >> logging. > > May I ask if other Org operations are also slow in that problematic file > with many markers? If so, I do not think that we need to worry about > performance of `line-number-at-pos'. Rather we just wait for Emacs to > fix problems with markers. See the discussion in https://yhetil.org/emacs-devel/jwvsfntduas.fsf-monnier+emacs@gnu.org Thank you for the link. It would be great if that branch were merged. My primary complain concerning line numbers is that there is no way to disable the feature. Ihor, the following is not answer to your question. I am impressed by such observation, however it is not latest Emacs version and built-in Org that uses overlays, not text properties. It seems, in the case of `line-number-at-pos' another "optimization" causes performance degradation by orders of magnitude, not markers as for conversion between byte offset and position in buffers. I have found a discussion of a change in Emacs-28 (So it is not clear for me why I see performance difference between Emacs-26 and 27, maybe more optimal code generated by newer gcc) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22763 25.1.50; Feature Request -- A faster method to obtain line number at position. I noticed `cache-long-scans' and tried to disable it. If my document (4Mb, 100k lines) is open as .txt file in Emacs-26 getting line number at the end takes 0.03…0.04 s. If I enable org-mode the same operation requires 6s, but after (setq cache-long-scans nil) 0.006 s is enough to get the same line number. Enabling the cache again causes performance degradation by 3 orders of magnitude. Cache works to some extent because first call takes 12 s while following ones "only" 6 s. I have not tried if disabling newline cache causes problems with other operation.