From: Dmitry Gutov <dgutov@yandex.ru>
To: Kim Storm <storm@cua.dk>
Cc: 12796@debbugs.gnu.org
Subject: bug#12796: Optimize `ido-completing-read' for larger lists with flex matching enabled
Date: Tue, 06 Nov 2012 19:38:45 +0400 [thread overview]
Message-ID: <50992F05.5090108@yandex.ru> (raw)
In-Reply-To: <5098EE91.9000906@cua.dk>
On 06.11.2012 15:03, Kim Storm wrote:
>> I'm not familiar with the ido.el code, so I find it difficult to judge
>> if your approach to caching is right. Kim could you take a look (the
>> patch can be seen at http://debbugs.gnu.org/12796)?
>
> I looked at the caching patch, and it looks alright (in the sense that I
> don't think
> it will break ido behaviour.)
>
> I'm not sure how efficient the caching is though. As far as I can see,
> it only
> caches the most recent (non-empty) list of matches, i.e. the shortest list
> corresponding to the longest "successful" user input in the minibuffer.
>
> So if the user has to backtrack beyond that point, I don't really see
> how the
> caching will help, as the cache is then invalidated.
That's true, backtracking was not a priority. But see below.
> Also, I don't quite understand why this condition is needed:
>
> (<= (* 10 (length matches)) (length ido-cur-list)))
>
> It seems to me to only cache a list of matches that has reduced
> the set of matches by a factor 10 - if the aim is to reduce processing
> time for long lists, even reducing by a factor of 2 may be noticable ?
>
> But maybe the intention of this line was to stop caching once the list
> has become short than 1/10th of the original list? In that case, the
> operator should be <= I think ?
No, the idea is to limit memory consumption (which may be a bit
premature) and make sure that the filtered matches list is smaller
enough than the original to justify saving it. I probably should change
10 to a smaller constant, like 3 or 2.
On the "stop caching" front, we can add a lower bound check, comparing
the matches length to an absolute or relative value. This way, doing a
few backspaces from a sufficiently narrowed state won't trigger a full
recomputation.
To go further than that, it shouldn't be hard to keep a stack of caches
for the current input string as it's typed, but I suspect memory
consumption may be a bigger concern in this case.
WDYT?
next prev parent reply other threads:[~2012-11-06 15:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-04 5:58 bug#12796: Optimize `ido-completing-read' for larger lists with flex matching enabled Dmitry Gutov
2012-11-04 8:32 ` Leo
2012-11-04 13:53 ` Stefan Monnier
2012-11-04 17:05 ` Dmitry Gutov
2012-11-05 5:37 ` Dmitry Gutov
2012-11-06 1:45 ` Stefan Monnier
2012-11-06 11:03 ` Kim Storm
2012-11-06 15:38 ` Dmitry Gutov [this message]
2012-11-06 16:45 ` Kim Storm
2012-11-07 5:41 ` Dmitry Gutov
2012-11-05 20:57 ` Dmitry Gutov
2012-11-07 2:27 ` Leo
2012-11-07 4:06 ` Dmitry Gutov
2012-11-07 10:38 ` Leo
2012-11-07 21:54 ` Dmitry Gutov
2012-11-08 2:00 ` Leo
2012-11-08 4:14 ` Stefan Monnier
2012-11-08 7:36 ` Leo
2012-11-08 14:05 ` Stefan Monnier
2012-11-10 17:52 ` Dmitry Gutov
2012-11-10 22:51 ` Stefan Monnier
2012-11-10 23:01 ` Dmitry Gutov
2012-11-10 23:31 ` Stefan Monnier
2020-09-13 16:14 ` Lars Ingebrigtsen
2012-11-08 2:05 ` Stefan Monnier
2012-11-08 4:29 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50992F05.5090108@yandex.ru \
--to=dgutov@yandex.ru \
--cc=12796@debbugs.gnu.org \
--cc=storm@cua.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.