From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id MAZuEGr4a2fazAAAe85BDQ:P1 (envelope-from ) for ; Wed, 25 Dec 2024 12:19:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id MAZuEGr4a2fazAAAe85BDQ (envelope-from ) for ; Wed, 25 Dec 2024 13:19:54 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A1DQ4C9B; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735129194; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=nCYDJNUN+5NZqd4VQls35mVImoFEUtRk0PrFVaAFtYE=; b=t8YAGh2x1Stk0OckZVzfg6nAXup84DKHY8hdP5UBKcNxXdquAEEVX+4G3fa1YZdekn4poU zz6lzW3rPqf7KmJzd4TZeptXNoEmqJs4K3nZvAQTDQ5PQKQoqXrViFj3k7i8FpsGwxXJPT ZY5QwRyW5A3AigI12wQcQ9iPJ5di4eeIoiNGqGyiug06RYRCCgpJ1al0eMbBlPLEb4Mtfc l8bRMSTRc6deQh/Zph01DhPEM6oFJqM3wrzBkRq3JYsUq5WDhuvPmDH5IHgE7EhmsXiWye 0HKo65I4hf3uNn6UGyF9JoVxpvvJe0Ix3l/qw1PhfY974qJtlQg/OCkkyjWKuA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A1DQ4C9B; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735129194; a=rsa-sha256; cv=none; b=LGxaAivfoozsViQMz6naM/6dkp5Y0kVxjlfpwJWcqTHH5bIT7hmo8nn3FVZ5jwk3TA5e3N sAB8edeD4h44JtwJOW6Ycm48UfgExPbzD7ynIOljhtyqtJ8FjKGPGi8gHwBqkEegAMhETh uIR4XA3/jbI9zhZV544kt9KOMV6Sk8mn4GkKvca/2bQcKZkkCE+ZnVuerJGeA0USviorfh 0IYY9CIG0P5N+5nitFKQpsEQ9Zgdx5AmTQt5mrdy8JnwWe1vS3y0+4y4KDa12bpKfsBu1e Uh2ZWdtzZyJCyPSuk60YvfaqPrMS9gv5HPlqgnBPxKiLqUtslGep/EnRQIoSxg== 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 1F6579DB04 for ; Wed, 25 Dec 2024 13:19:54 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQQM6-00056Q-FM; Wed, 25 Dec 2024 07:19:14 -0500 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 1tQQM3-000568-2Y for emacs-orgmode@gnu.org; Wed, 25 Dec 2024 07:19:12 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQQM0-0007Zr-Er for emacs-orgmode@gnu.org; Wed, 25 Dec 2024 07:19:10 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 965CB240027 for ; Wed, 25 Dec 2024 13:19:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735129143; bh=OyxDKM4d4BEomylNHWv9pYhMdTK+1GQi5R2GIVskX5Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=A1DQ4C9BlGhcFgjIWBEblFrUNfY3LzyZ/JnHEBtaQNXpaENlduVVIx38YVy8JV9/R xQVkeGoCRSVIYXXnFbbCT2hZ5lQmVdvFUmP2RcY6QwHcCdGmKdsFpa7c+vpuy3afSO z1KbxMlO0p3P++joQ2xSj0JiRSnVsnWM4Jg6iZhRhWxWsNYJWcN77VaCk0u6r4ZMAY 5cITKhsHSWaTZC+BNKTQUo2NgkEAVmXafLKoRkj+tv9pqjvhZu6MnX2srW75Chr5xB Ind95EqFTCI/So27TIYG2kWC96H9aUf0MO7mL7m+MWSogDJxcMYTmvx2Ve80+BBFLc TTUuG+P3uB0aQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YJ9m66JkLz6tm4; Wed, 25 Dec 2024 13:19:02 +0100 (CET) From: Ihor Radchenko To: "Dwarshuis, Nathan J" Cc: org-mode-email Subject: Re: [PATCH] org-element.el; significant optimizations for org-element--interpret-affiliated-keywords In-Reply-To: <87v7w5pswu.fsf@yavin4.ch> References: <87v7w5pswu.fsf@yavin4.ch> Date: Wed, 25 Dec 2024 12:20:33 +0000 Message-ID: <877c7o0x9q.fsf@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -8.98 X-Spam-Score: -8.98 X-Migadu-Queue-Id: 1F6579DB04 X-Migadu-Scanner: mx10.migadu.com X-TUID: qruF89CWt8zT --=-=-= Content-Type: text/plain "Dwarshuis, Nathan J" writes: > I noticed that calling `org-element-interpret-data' on objects is > generally 5-10x faster than when calling on elements. The reason seems > to be that `org-element--interpret-affiliated-keywords' (which is only > called on elements) does alot of unnecessary work. Namely, it runs on > all elements (including those that should never have an affiliated > keyword) > > The attached patch addresses this. Thanks! I am attaching some extra suggestions on top of the patch. > ... and also loops over :standard-properties which should not be > relevant here. There is nothing stopping us from adding some affiliated keywords to standard properties in future. What happens if you drop this optimization? Does the benchmark still show an improvement? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-suggestions.patch >From 0301efb86b994e2c79a37c21f17c664c1193d4c0 Mon Sep 17 00:00:00 2001 Message-ID: <0301efb86b994e2c79a37c21f17c664c1193d4c0.1735129004.git.yantar92@posteo.net> From: Ihor Radchenko Date: Wed, 25 Dec 2024 13:16:36 +0100 Subject: [PATCH] suggestions --- lisp/org-element.el | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 3b90dce2a2..d386ee4184 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -338,7 +338,8 @@ (defconst org-element-object-containers (defconst org-element-elements-no-affiliated '(org-data comment clock headline inlinetask item node-property planning property-drawer - section table-row)) + section table-row) + "List of paragraph-level node types that cannot have affiliated keywords.") (defconst org-element-affiliated-keywords '("CAPTION" "DATA" "HEADER" "HEADERS" "LABEL" "NAME" "PLOT" "RESNAME" "RESULT" @@ -5522,7 +5523,8 @@ (defun org-element-interpret-data (data) (make-string blank ?\n))))))))) (funcall fun data nil))) -(defun org-element--keyword-to-org (key value) +(defun org-element--interpret-affiliated-keyword (key value) + "Interpret affiliated keyword with KEY and VALUE." (let (dual) (when (member key org-element-dual-keywords) (setq dual (cdr value) value (car value))) @@ -5540,28 +5542,30 @@ (defun org-element--interpret-affiliated-keywords (element) If there is no affiliated keyword, return the empty string." ;; there are some elements that will never have affiliated keywords, ;; so do nothing for these - (if (member (org-element-type element) org-element-elements-no-affiliated) + (if (member (org-element-type element) + org-element-elements-no-affiliated) "" (let (acc) (org-element-properties-resolve element t) (org-element--properties-mapc (lambda (prop value) (when value - (let ((keyword (upcase (substring (symbol-name prop) 1)))) - (when (or (string-match-p "^ATTR_" keyword) + (let* ((keyword (upcase (substring (symbol-name prop) 1))) + (attrp (string-match-p "^ATTR_" keyword))) + (when (or attrp (and (member keyword org-element-affiliated-keywords) (not (assoc keyword - org-element-keyword-translation-alist)))) - (push (if (or (member keyword org-element-multiple-keywords) - ;; All attribute keywords can have multiple lines. - (string-match-p "^ATTR_" keyword)) - (mapconcat (lambda (line) (org-element--keyword-to-org keyword line)) - value "") - (org-element--keyword-to-org keyword value)) + org-element-keyword-translation-alist)))) + (push (if (or attrp ; All attribute keywords can have multiple lines. + (member keyword org-element-multiple-keywords)) + (mapconcat + (lambda (line) (org-element--interpret-affiliated-keyword keyword line)) + value "") + (org-element--interpret-affiliated-keyword keyword value)) acc))))) - element nil t) - (apply #'concat (nreverse acc))))) + element nil t) + (apply #'concat (nreverse acc))))) ;; Because interpretation of the parse tree must return the same ;; number of blank lines between elements and the same number of white -- 2.47.1 --=-=-= Content-Type: text/plain -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at --=-=-=--