I use async with Dired copy/move/rename, but deletion somehow does not work. On top of it when deleting +100 files the deletion is very slow. Anyone knows a remedy for either: 1. Faster file deletion, 2. Async file deletion?

I also just tried some deletions via Neotree and the outcome is the same, meaning very slow. Which means that both the packages are using the same deletion method, probably delete-file and delete-directory. The question still remains, why are they so slow?

Copying those exacts same file via Dired to a new location is faster than deleting them. To copy it takes 0.5s, to delete 17s !!!! Removal via any other application in the system takes the approriate close to 0s time...

2 Answers 2


One possibility is that the slowness is due to the post-deletion clean-up that dired carries out (asking whether to kill the buffers corresponding to the deleted files etc.).

You could test what exactly is the cause by writing your own dired-do-delete and dired-internal-do-deletions (dired-do-delete is just a wrapper), by either mutilating the existing function and carefully removing features/error-testing or starting with a basic function and re-adding features. The core functions are dired-delete-file and, recursively, delete-file.

For the record, I don't really have this issue with emacs (either 24.4 or master) on Linux, on ext4 — deleting several hundred files with dired takes less than a second. Deleting 10000 small files (generated via for i in $(seq 1 10000); do echo "$i" > "$i"; done ) takes 9 seconds.

  • I'll look into this once I'll find some time. I really appreciate the insight. Commented Aug 28, 2017 at 15:18
  • 1
    I just tested the deletion with dired on emacs -Q and it is blazing fast like it is supposed to be. It seems that one of my packages is doing this then. I guess that when I'll find some time I'll try and disable dired packages one by one to narrow this down. First I'll toggle all the custom setq , just in case if one of them is being naughty. Commented Aug 28, 2017 at 15:39

It seems that the culprit is Eclim: enter image description here After deleting the Eclim package, the file deletion via Dired or Neotree is fast again. I do wonder why does Eclim get involved in this in the first place? I'll open an issue on their github.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.