From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: ANN: org-ql agenda block support Date: Sat, 31 Aug 2019 00:20:52 -0500 Message-ID: <87ftlhlxl7.fsf@alphapapa.net> References: <87ftmb7l27.fsf@alphapapa.net> <87h86m75pu.fsf@eml.cc> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56320) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3vp3-0008IC-L2 for emacs-orgmode@gnu.org; Sat, 31 Aug 2019 01:21:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3vp2-0005e8-H0 for emacs-orgmode@gnu.org; Sat, 31 Aug 2019 01:21:13 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:45004 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i3vp2-0005X1-7s for emacs-orgmode@gnu.org; Sat, 31 Aug 2019 01:21:12 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i3vou-00035E-P3 for emacs-orgmode@gnu.org; Sat, 31 Aug 2019 07:21:04 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Mikhail Skorzhinskii writes: > Adam Porter writes: > > However, the org-ql-block version runs in about 1/5th the time (0.7 > > seconds compared to 3.45 seconds on my collection of org-agenda-files). > > For some reason I thought that on average org-ql package is working > slower then native org-agenda searches. Probably because there are more > control and interface is much more simpler and cleaner and nothing > comes free of charge. That sort of thing. :-) Well, it might also be because it used to be generally slower, and I tried to be clear about that whenever I mentioned it. :) But I've applied a lot of optimizations to it over the past few months, so it's generally pretty fast now, sometimes much faster. It's hard to make a direct comparison in some cases, depending on the complexity of the query. I plan to continue optimizing it as I'm able, so hopefully it will continue improving. > I am really glad that I was mistaken. Care to drop a few thoughts on why > this is the case? This is applicable only for ql-block or other org-ql > functions are a bit faster too? Well, it's a completely different implementation. It has two main features which attempt to make it fast: it uses regexp searches across buffers as much as possible, similar to org-agenda.el but in a more flexible way (though there's still room for improvement here, especially with complex queries); and it caches results keyed on the query, buffer, and narrowing (cached results are discarded when a buffer is modified), which avoids re-running the same queries for unmodified buffers. Oh, and it also byte-compiles query predicates and action functions to eke out a bit more speed. And in general, I run benchmarks and try to improve performance when possible; you can see some of the benchmark results in the notes.org file in the repo (not all of which are up-to-date with current org-ql code). org-ql-block is just a way to make use of the results returned by org-ql queries; other ways include org-ql-agenda, org-ql-search, and of course you can use the raw results however you like, including calling whatever :action function you like at matching entries, to return whatever kind of data you need, or even perform actions directly on entries. In other words, the querying code is separate from the display-related code, so all org-ql-block, org-ql-agenda, org-ql-search, etc. do is format results from org-ql queries and display them. Upcoming features include an org-ql-sparse-tree command, like org-sparse-tree but using org-ql queries; recursive queries; and probably a timeline view like I recently posted about. Please let me know if you have any feedback!