Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow rendering of the files list #43

Closed
Anks opened this issue Nov 15, 2017 · 6 comments
Closed

Slow rendering of the files list #43

Anks opened this issue Nov 15, 2017 · 6 comments

Comments

@Anks
Copy link

Anks commented Nov 15, 2017

I have over 1000 different files in my deft directory.

Over time, deft has started to feel very slow while filtering: there is a noticeable delay with every key press while filtering files.

My first assumption was that incremental search might be slow, but a little profiling revealed that most of the time is spent in these lines of the deft-buffer-setup function:

      (if deft-current-files
          (progn
            (mapc 'deft-file-widget deft-current-files))
        (widget-insert (deft-no-files-message))))

I'm not sure if it's something wrong with my local emacs configuration: I'm running emacs-mac with font composition enabled via mac-auto-operator-composition-mode. I haven't noticed a slowdown in any other modes though.

For now, I have locally edited this function to show the first 10 files from deft-current-files. This fixes the problem for me – typing / filtering feels realtime again, without any perceived delay.

I just wanted to report this. If anyone else has noticed a similar problem, I can provide a PR which will let you customise the total number of files displayed in deft.

@jrblevin
Copy link
Owner

Thanks for reporting this. I can confirm a similar result when profiling, although I only have about 300 notes at the moment.

I think rather than limiting the number of lines rendered (which would prevent being able to scroll down and see more), to solve the underlying issue a better approach would be a slight redesign where the widget and summary line for each file is created once and stored for re-use. I can't tackle that at the moment, but if anyone wants to take a shot at that I'll certainly accept at a PR.

@Anks
Copy link
Author

Anks commented Dec 8, 2017

Small update: for my personal use, I ended up defining a advice function like this which limits the display to 30 files:

  ;; Overwrite `deft-current-files` for the `deft-buffer-setup` and limit it to 30 entries
  (defun anks-deft-limiting-fn (orig-fun &rest args)
    (let
        ((deft-current-files (-take 30 deft-current-files)))
      (apply orig-fun args)))

  (advice-add 'deft-buffer-setup :around #'anks-deft-limiting-fn)

This gives me snappy search, and 30 results are 'good enough'.

This is probably not the best solution, but works for me.

Note: the -take function is from dash.el

Anks added a commit to Anks/elisp that referenced this issue Dec 11, 2017
Issue: jrblevin/deft#43

Temp fix: use a advising function to limit `deft-current-files` to 30
items, which speeds up rendering.
@joech4n
Copy link

joech4n commented Sep 2, 2018

Update: Nvm, user error. :)

@Anks I'm seeing this error with your snippet after adding to dotspacemacs/user-config, any idea why?

(Spacemacs) Error in dotspacemacs/user-config: Wrong type argument: symbolp, (defalias (quote anks-deft-limit\
ing-fn) (function (lambda (orig-fun &rest args) (let ((deft-current-files (-take 30 deft-current-files))) (ap\
ply orig-fun args)))))

@Henry-T
Copy link

Henry-T commented Sep 4, 2018

@joech4n why added into a (defalias (quote ...)) block?
I just added directly under user-config, it works quite well

@jrblevin
Copy link
Owner

I added built-in support for limiting the number of files shown via `deft-file-limit'. See the updated README and the docstring for details.

@Anks
Copy link
Author

Anks commented Dec 28, 2018

@jrblevin Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants