Hello,
Adam Porter writes:
> Yes, because this is the fastest way to search for matching entries in a
> buffer, when it's possible to use a regexp search.
You would still do regexp searches, but not at the time of queries.
> That would be ideal. The problem I foresee is that, when a buffer's c
On Oct 18, 2018 5:48 PM, "Nicolas Goaziou" wrote:
> Are you saying that queries are turned into regexp searches within Org
files? If so, I don't think they should.
Yes, because this is the fastest way to search for matching entries in a
buffer, when it's possible to use a regexp search.
> Queri
>> However, before it could be suitable as a possible replacement, it will
>> likely require more optimization. Some queries, especially more complex
>> ones, are slower than the equivalent searches and agendas in the current
>> Org Agenda code. This is because of the way the queries run predic
Hello,
Adam Porter writes:
> Org is welcome to take any of the org-ql or org-ql-agenda code you think
> would be useful.
Thank you.
> However, before it could be suitable as a possible replacement, it will
> likely require more optimization. Some queries, especially more complex
> ones, are s
Nicolas Goaziou writes:
> It can, but AFAIK, it doesn't yet. It also means un-optimized lexical
> binding may be slightly slower than dynamic scoping for the time
> being.
Well, I can't vouch for it myself, because I haven't studied the code.
But here's one of the resources that suggests it is f
Hello,
Adam Porter writes:
> From what I've read, the byte-compiler can optimize better when
> lexical-binding is used.
It can, but AFAIK, it doesn't yet. It also means un-optimized lexical
binding may be slightly slower than dynamic scoping for the time being.
> I've thought about this for a
> I've thought about this for a while. It seems to me that the issue is
> that Org buffers are, of course, plain-text buffers. There is no
> persistent, in-memory representation other than the buffer, so whenever
> Org needs structured/semantic data, it must parse it out of the buffer,
>
Nicolas Goaziou writes:
>> my understanding is that code that runs with lexical-binding enabled
>> is generally faster.
>
> Not really. But it's certainly easier to understand since it removes one
> class of problems.
>From what I've read, the byte-compiler can optimize better when
lexical-bindi
On 2018-10-11, at 21:59, Samuel Wales wrote:
> i too visit all files when emacs starts.
>
> are we saying that the speed depends on the number of headlines total
> or the number of headlines in a single file among the agenda files?
Probably the former...?
>
> On 10/11/18, Marcin Borkowski wr
On 2018-10-11, at 08:40, Michael Welle wrote:
> Hello,
>
> Marcin Borkowski writes:
>
>> On 2018-10-09, at 13:47, Julius Dittmar wrote:
>>
>>> Hi Marcin,
>>>
>>> I can't advise as to profiling to find out what really bogs down agenda
>>> building.
>>>
>>> I found that log messages do bog it d
i too visit all files when emacs starts.
are we saying that the speed depends on the number of headlines total
or the number of headlines in a single file among the agenda files?
On 10/11/18, Marcin Borkowski wrote:
>
> On 2018-10-11, at 08:48, Michael Welle wrote:
>
>> Hello,
>>
>> Marcin Bork
On 2018-10-11, at 08:48, Michael Welle wrote:
> Hello,
>
> Marcin Borkowski writes:
>
>> On 2018-10-08, at 09:20, Michael Welle wrote:
> [...]
>>> Well, on my laptop the initial agenda run takes about 7s or so (150
>>> agenda files) using the current day/week agenda ("a"). All subsequent
>>>
Hello,
Marcin Borkowski writes:
> On 2018-10-08, at 09:20, Michael Welle wrote:
[...]
>> Well, on my laptop the initial agenda run takes about 7s or so (150
>> agenda files) using the current day/week agenda ("a"). All subsequent
>> (after loading the files) agenda runs are fast (split second I
Hello,
Marcin Borkowski writes:
> On 2018-10-09, at 13:47, Julius Dittmar wrote:
>
>> Hi Marcin,
>>
>> I can't advise as to profiling to find out what really bogs down agenda
>> building.
>>
>> I found that log messages do bog it down.
>>
>> I have a lot of recurring tasks, which accumulate log
for cleaning logbook entries, i'd enjoy having an agenda view that
shows every entry that has state changes [above a minimum number of
them to keep it small], with the size of the logbook drawer in the
prefix or so next to the category, sorted by that size.
there would be a corresponding agenda ba
On 2018-10-08, at 09:20, Michael Welle wrote:
> Hello,
>
> Marcin Borkowski writes:
>
>> Hi Orgers,
>>
>> my agenda takes almost 10 seconds to show up. Are there any ideas for
>> profiling that?
>>
>> I suspect that archiving a lot of old entries I don't use anymore might
>> help, but is ther
On 2018-10-09, at 13:47, Julius Dittmar wrote:
> Hi Marcin,
>
> I can't advise as to profiling to find out what really bogs down agenda
> building.
>
> I found that log messages do bog it down.
>
> I have a lot of recurring tasks, which accumulate log entries for every
> closing (which in fact
On 2018-10-09, at 18:11, Nicolas Goaziou wrote:
> Hello,
>
> Adam Porter writes:
>
>> My feedback is: there be dragons. ;) The Agenda code is very
>> complicated and hard to follow, and it's hard to optimize something that
>> is hard to understand.
>
> And hard to maintain. We should really
On 2018-10-09, at 08:37, Adam Porter wrote:
> Hi Marcin,
>
> [...]
>
> If you haven't seen them already, you may find my org-ql and
> org-ql-agenda code useful. org-ql-agenda presents an Agenda-like
> buffer. N.B. It does *not* implement most of the Agenda features, but
> it does emulate an O
Hello,
Adam Porter writes:
> My feedback is: there be dragons. ;) The Agenda code is very
> complicated and hard to follow, and it's hard to optimize something that
> is hard to understand.
And hard to maintain. We should really do something about it.
> In the long run, to get significant sp
Hi Marcin,
I can't advise as to profiling to find out what really bogs down agenda
building.
I found that log messages do bog it down.
I have a lot of recurring tasks, which accumulate log entries for every
closing (which in fact means rescheduling to the next day). Every two to
three months I p
Hi Marcin,
My feedback is: there be dragons. ;) The Agenda code is very
complicated and hard to follow, and it's hard to optimize something that
is hard to understand.
In the long run, to get significant speed improvements, I think it may
be necessary to reimplement the Agenda. However, due to
Hello,
Marcin Borkowski writes:
> Hi Orgers,
>
> my agenda takes almost 10 seconds to show up. Are there any ideas for
> profiling that?
>
> I suspect that archiving a lot of old entries I don't use anymore might
> help, but is there any way to e.g. display some stats on which
> file/headline t
23 matches
Mail list logo
