From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mikhail Skorzhinskii Subject: Re: ANN: org-ql agenda block support Date: Thu, 12 Sep 2019 21:19:01 +0200 Message-ID: <87tv9h8gre.fsf@eml.cc> References: <87ftmb7l27.fsf@alphapapa.net> <87h86m75pu.fsf@eml.cc> <87ftlhlxl7.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39375) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8Ui6-0005PQ-Fc for emacs-orgmode@gnu.org; Thu, 12 Sep 2019 15:24:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i8Ui5-0005YG-Aw for emacs-orgmode@gnu.org; Thu, 12 Sep 2019 15:24:54 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:56867) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i8Ui4-0005X1-VT for emacs-orgmode@gnu.org; Thu, 12 Sep 2019 15:24:53 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 925F05F8 for ; Thu, 12 Sep 2019 15:24:50 -0400 (EDT) Received: from AlphaTux (95.157.54.228.dynamic.cablesurf.de [95.157.54.228]) by mail.messagingengine.com (Postfix) with ESMTPA id 91ACFD6005B for ; Thu, 12 Sep 2019 15:24:49 -0400 (EDT) In-reply-to: <87ftlhlxl7.fsf@alphapapa.net> 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 Great overview, thanks a lot. So I give it a try and completely fell in love. On my data set it is visibly faster then org-agenda. I also wrote a lot of code around org-agenda over the years to support my sometimes awkward needs. And now I just threw all this ugly code away! That was very emotional moment for me, very good job, kind sir. Adam Porter writes: > 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!