emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org


From: Ihor Radchenko
Subject: Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Date: Sat, 09 May 2020 23:43:36 +0800

> The visual glitch looks like that:
> 
> :PROPERTIES:X:CREATED:  [2020-05-04 Mon 18>54]
> X

Should be partially fixed in the latest patch I just sent.

OLD <<< :PROPERTIES:X:CREATED:  [2020-05-04 Mon 18>54]

NEW >>> :PROPERTIES:X X

Best,
Ihor

Karl Voit <address@hidden> writes:

> Hi Ihor,
>
> * Ihor Radchenko <address@hidden> wrote:
>>
>> So far, I came up with the following partial solution searching and
>> showing hidden text.
>>
>> (defun org-find-text-property-region (pos prop)
>> (define-advice isearch-search-string (:after (&rest _) put-overlay)
>> (defun org-restore-invisibility-specs (&rest _)
>> (add-hook 'post-command-hook #'org-restore-invisibility-specs)
>> (defun org-flag-region (from to flag spec)
>> (defun org-unfontify-region (beg end &optional _maybe_loudly)
>
> After a couple of hours working with these patches, my feedback is
> very positive. Besides some visual glitches when creating a new
> heading with org-expiry-insinuate activated (which automatically
> adds :CREATED: properties), I could not detect any side-effect so
> far (will keep testing).
>
> The visual glitch looks like that:
>
> :PROPERTIES:X:CREATED:  [2020-05-04 Mon 18>54]
> X
>
> ... with "X" being my character that symbolizes collapsed content.
> The way it looked without the patch was a simple collapsed property
> drawer.
>
> To me, this is acceptable considering the huge performance gain I
> got.
>
> THANK YOU VERY MUCH! I can't remember where I had this way of
> working within my large Org files[3] since ages.
>
>>> Anyway, the real fix should come from Emacs itself. There are ways to
>>> make overlays faster. These ways have already been discussed on the
>>> Emacs devel mailing list, but no one implemented them. It is a bit sad
>>> that we have to find workarounds for that.
>>
>> I guess that it is a very old story starting from the times when XEmacs
>> was a thing [1]. I recently heard about binary tree implementation of
>> overlays (there should be a branch in emacs git repo) [2], but there was
>> no update on that branch for a while. So, I do not have much hope on
>> Emacs implementing efficient overlay access in the near future. (And I
>> have problems with huge org files already).
>
> I can not express how this also reflects my personal situation.
>
>> [1] 
>> https://www.reddit.com/r/planetemacs/comments/e9lgwn/history_of_lucid_emacs_fsf_emacs_schism/
>> [2] https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00323.html
>
> [3] https://karl-voit.at/2020/05/03/current-org-files
>
> -- 
> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
>
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: address@hidden, address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]