From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id YIlfIJfxVV+tEgAA0tVLHw (envelope-from ) for ; Mon, 07 Sep 2020 08:38:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KKIoHJfxVV8KUgAAbx9fmQ (envelope-from ) for ; Mon, 07 Sep 2020 08:38:47 +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 BDF069400EF for ; Mon, 7 Sep 2020 08:38:46 +0000 (UTC) Received: from localhost ([::1]:50204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFCfl-0005zU-Ki for larch@yhetil.org; Mon, 07 Sep 2020 04:38:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFCf7-0005Qz-0t for emacs-orgmode@gnu.org; Mon, 07 Sep 2020 04:38:05 -0400 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]:38912) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFCf4-0005xL-Ox for emacs-orgmode@gnu.org; Mon, 07 Sep 2020 04:38:04 -0400 Received: by mail-pl1-x631.google.com with SMTP id x18so4170485pll.6 for ; Mon, 07 Sep 2020 01:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=oGBhuoiHCP5Nz6ehTqNxvUHBu6gD4TG/V2jxeHKFHGY=; b=ooedh8LMQhi5QcEfzuNaxn1wKh1ED1Bv0OqtOdObY1GeS3v5YjSWc/r53fXaB6BTNB mXN6Vz5HXQilqKFqCAqHJZ3LAWAjZ2obP9A/BqOPJnR8YuBnWkTpIbb1CGF6NZp3qBGw dMKskvx0ZJeu6BIdYGW/usTE7EYuB3WdxyRGTx4n6N0NF570+M2Vd5xyXqVnsP/rrCRu j3WjdCaGhuVagBeptN4/WGa/VbJWo8FYwLtPlU3PGnusxA+IZihDwoM81ZS7t0pdjLsm GDeTi/+CWTypmp/ERaOW1bJJ/nRPsUIkGLJvet4WulXlSXcRSj4RPPRii1gn+XvZed27 lgNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=oGBhuoiHCP5Nz6ehTqNxvUHBu6gD4TG/V2jxeHKFHGY=; b=qk2ZF43OPEEePl0JbQmMC3R1LuAQb+EtZm/IynyZej95iJzDOD7OfE5vpP7rX+bZeY rw55oOpN6nD3Hn6VGXiyx3uq95vYsBX4KHPava9E7EVw0TicKPSjAj53DSIDvyHwHn1r LWDwdp0AmHraeV/O4KsRVyZkXGQk6KcnS85TK66u4IsOBWv8s76cbg84ahiqYhw0P0x4 GkloF1fPkKHQaFESXqJovu30sYxTuPblqvFeLjH6qQ/Ueg018P1g0caxBPzB5DZxVrgc rQ+412MfEv6F+VjwqS+OnKGB7ZvH2tJZosnz28GFIvHSkUmRW4ECsPvicO0BOtH3QZOK CFdg== X-Gm-Message-State: AOAM533QRCWhxNzDLtDi8IdOGDZY+Yh3tLUgebiVTXA7E7UZPsQOTNeI jEWRZUXVu6lg3ouYgydMf/E= X-Google-Smtp-Source: ABdhPJyLHa+k8h7g2Mhb1jsv1ZX42jMobRv9TMh5ownihZ6HlP6hgFEge/witkRY+5WarvTKGlxNpw== X-Received: by 2002:a17:90a:9282:: with SMTP id n2mr19444992pjo.219.1599467880766; Mon, 07 Sep 2020 01:38:00 -0700 (PDT) Received: from localhost ([167.88.61.176]) by smtp.gmail.com with ESMTPSA id ie13sm12357295pjb.5.2020.09.07.01.37.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2020 01:38:00 -0700 (PDT) From: Ihor Radchenko To: Daryl Manning Subject: Re: Improving org-contacts performance (and state of development in general) In-Reply-To: References: <87imcqz5ig.fsf@localhost> Date: Mon, 07 Sep 2020 16:36:58 +0800 Message-ID: <877dt6yod1.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::631; envelope-from=yantar92@gmail.com; helo=mail-pl1-x631.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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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=gmail.com header.s=20161025 header.b=ooedh8LM; dmarc=pass (policy=none) header.from=gmail.com; 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: -1.21 X-TUID: 9ozxdaIq6K5M > tho quite interested in seeing what perf enhancements you've done on large > org files would be interesting. That's primarily a one single enhancement - use text properties instead of overlays to hide/fold text. Overlays are slow - every time Emacs need to move point across hidden overlays, it takes O(N_overlays). The problem especially affects buffers with many property drawers (every drawer may require an individual overlay) - should be the case for org-contacts files. > 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. I did some benchmarks on my agendas with and without my enhancements - my main agenda builds in around 7sec now in comparison with 18-20sec when using overlays. Though 20sec benchmark was not on current master, there were several commits reducing the number of overlays in some cases after I did the benchmark. Also, you may consider native-comp branch. It can push the speed even further. My agenda only took 3-4 seconds on native-comp Emacs branch. > 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. I guess it is a job for [future] ox-*.el packages. Best, Ihor Daryl Manning writes: > 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. >>