From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wFoDCpigVV9TGwAA0tVLHw (envelope-from ) for ; Mon, 07 Sep 2020 02:53:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0HjeBZigVV8jYgAAB5/wlQ (envelope-from ) for ; Mon, 07 Sep 2020 02:53:12 +0000 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 5553B94044B for ; Mon, 7 Sep 2020 02:53:11 +0000 (UTC) Received: from localhost ([::1]:55382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kF7HI-0004is-Nq for larch@yhetil.org; Sun, 06 Sep 2020 22:53:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kF7Gy-0004ij-6l for emacs-orgmode@gnu.org; Sun, 06 Sep 2020 22:52:48 -0400 Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:35922) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kF7Gv-0006Go-UT for emacs-orgmode@gnu.org; Sun, 06 Sep 2020 22:52:47 -0400 Received: by mail-ua1-x92c.google.com with SMTP id l1so3765865uai.3 for ; Sun, 06 Sep 2020 19:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakatara.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pmgIPQSwz6rzntPRFOWRoTw5/C63W0KRGl+db+unhrs=; b=oBdO+EAESIjsTiPkDwwL05t5WTgf1jtkVKCdzRPckXHamBykoBchu/yWhriS3UVM+T 6cM+wZ/KzZg5pNOdMpAHWGOPQmK08w+ndPEjedJAtsv1O1DjY48hmhp7vAWnROqqJnMm CDh5/M1S3eXFSgbE2TV6dlU7Y3VAU6FasTc25s4h7De6cU27m2vpD5nkh0+mzEiTAmjP u40YwPfWZh1TLulPiSFtOX5eyvkm5ETTcHeKPks/f1ZvK2AFqrukpuqybM44wyhzFC5a l68oIEfFWPghDGYjgVH7Va9uMLdnmYk/S0MX7hfFRHhJqQicBTPPC3aGFd+kuHmhbapB 3KnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pmgIPQSwz6rzntPRFOWRoTw5/C63W0KRGl+db+unhrs=; b=IxK1IkduLVmnJA7nJN4O77Qw/AS2WY79LqRWZ3uXXSLnjR6ZyeysMDRpsBSt0yyqlc Iz8uInR+0+Y6D1i0cC/J+AmECBX+v+1l48FWO52buOKKKdKwQk4uRRYPoii1z8kG9Bfi HC0f8M9gr/fMaZM4lxeCv1h6Gb9yURSM93LnE9Ex1TqG34vjWQ4JM5DLBnCiOlkUt2C1 xv9pF9Y2A5a91r/SqzrB7WEAutGVTBD8B5gXdkzweAUbR4GC+ioVFTofAF20sbGqHqWt jIpgBG/N794lyRdk/X2xvosi1em1bsSfN4b0QWW22tFwRl3ti6WpG2bQ2MlY717tynrh v03Q== X-Gm-Message-State: AOAM530/bkJN7+rfr3fTOU4X9WpN0sr6wrx3voIUwnQC/m+GlTVhRtrk oiCbrD5H48Gtj5JTtgUgWMvyrC3ZtwTL5KJNDgQF5g== X-Google-Smtp-Source: ABdhPJxsaKiaf871J7fiK/GghQ0WfIqnzJUqetcse5UL0XhAcJZxvHzY7BiZYTBxeY/M89F+fO8FpA9nt0wDZxjIzVQ= X-Received: by 2002:ab0:679a:: with SMTP id v26mr10144175uar.27.1599447164482; Sun, 06 Sep 2020 19:52:44 -0700 (PDT) MIME-Version: 1.0 References: <87imcqz5ig.fsf@localhost> In-Reply-To: <87imcqz5ig.fsf@localhost> From: Daryl Manning Date: Mon, 7 Sep 2020 10:52:08 +0800 Message-ID: Subject: Re: Improving org-contacts performance (and state of development in general) To: Ihor Radchenko Content-Type: multipart/alternative; boundary="00000000000013911705aeb05090" Received-SPF: pass client-ip=2607:f8b0:4864:20::92c; envelope-from=daryl@wakatara.com; helo=mail-ua1-x92c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Org-mode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=oBdO+EAE; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.21 X-TUID: E/sujSDiacvT --00000000000013911705aeb05090 Content-Type: text/plain; charset="UTF-8" Primary examples would be adding a note (CTRL-z) or changing a tag on a person and then having org-agenda update that. I am assuming it is because the entire file needs to be parsed rather than say, some index of entries. (so perhaps I mischaracterized org-contacts as being slow versus its interaction with other programs.) (for search I use swiper which is very efficient for searching the file whenI need it.). tho quite interested in seeing what perf enhancements you've done on large org files would be interesting. Daryl. PS> As an outside feature though, interoperability of the org-contact formats with other operating system address books, most notable gnome contacts/evolution, goog contacts, and OSX address book would be high on my list in terms of improving org-contacts though. (eg, raw, structued info in all address books, and say perhaps notes or similar maintained and synced in ome manner. On Mon, Sep 7, 2020 at 10:27 AM Ihor Radchenko wrote: > > However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > Could you provide some examples what exactly is being slow? > Maybe my WIP work on improving performance on large org files [1] might > help. > > Best, > Ihor > > [1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127740.html > > > Daryl Manning writes: > > > Strangely, I've come to rely over the last year on org-contacts as a > > lightweight, taggable CRM. However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > > > Is there a solid, forked branch anywhere that focuses on enhancing > > performance anywhere? I'm tempted to wade in and add features and > > improvements myself but my elisp-fu is dodgy at best (more golang these > > days.). > > > > I'd be interested in what people are doing to speed it up (and if it is > > under anything like active development for improvements. It does feel > super > > handy, and feels like it just needs a performance and more modern > features > > overhaul - more on interoperability and less on in-emacs > interoperability.). > > > > Would love to hear what people have done overall workflow wise if they > are > > using it seriously. > > > > thanks, > > Daryl. > --00000000000013911705aeb05090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Primary examples would be adding a note (CTRL-z) or c= hanging a tag on a person and then having org-agenda update that. I am assu= ming it is because the entire file needs to be parsed rather than say, some= index of entries.

(so perhaps I mischaracter= ized org-contacts as being slow versus its interaction with other programs.= )

(for search I use swiper which is very efficient= for searching the file whenI need it.).

tho quite= interested in seeing what perf enhancements you've done on large org f= iles would be interesting.

Daryl.
P= S> As an outside feature though, interoperability of the org-contact for= mats with other operating system address books, most notable gnome contacts= /evolution, goog contacts, and OSX address book would be high on my list in= terms of improving org-contacts though. (eg, raw, structued info in all ad= dress books, and say perhaps notes or similar maintained and synced in ome = manner.



On Mon, Sep 7, 2020 at 10:27= AM Ihor Radchenko <yantar92@gmail= .com> wrote:
> However, as the file and C-z notes have grown,
> performance has really started to drag. I know people have used variou= s
> schemes (caching) etc to try to improve performance and the like, but<= br> > updates to the file are taking a solid 5 seconds now when making major=
> updates and moving tags around.

Could you provide some examples what exactly is being slow?
Maybe my WIP work on improving performance on large org files [1] might
help.

Best,
Ihor

[1] https://www.mail-archive.com/em= acs-orgmode@gnu.org/msg127740.html


Daryl Manning <dwm+orgmode@wakatara.com> writes:

> Strangely, I've come to rely over the last year on org-contacts as= a
> lightweight, taggable CRM. However, as the file and C-z notes have gro= wn,
> performance has really started to drag. I know people have used variou= s
> schemes (caching) etc to try to improve performance and the like, but<= br> > updates to the file are taking a solid 5 seconds now when making major=
> updates and moving tags around.
>
> Is there a solid, forked branch anywhere that focuses on enhancing
> performance anywhere? I'm tempted to wade in and add features and<= br> > improvements myself but my elisp-fu is dodgy at best (more golang thes= e
> days.).
>
> I'd be interested in what people are doing to speed it up (and if = it is
> under anything like active development for improvements. It does feel = super
> handy, and feels like it just needs a performance and more modern feat= ures
> overhaul - more on interoperability and less on in-emacs interoperabil= ity.).
>
> Would love to hear what people have done overall workflow wise if they= are
> using it seriously.
>
> thanks,
> Daryl.
--00000000000013911705aeb05090--