Re: emacs slow on dired renaming

[Robert Marshall]

On Thu, Apr 03 2014, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Robert Marshall <spam@capuchin.co.uk>
>> Date: Thu, 03 Apr 2014 07:57:14 +0100
>> 
>> I have a build of emacs from the bzr trunk (of last week) for which
>> dired renaming of files is very slow. It takes around 60 seconds to move
>> 16 files to a subdirectory of their current location (within the same
>> filesystem). The delay is spread across the files so each rename appears
>> to take the same (c 5 seconds) time.
>
> Try profiling Emacs with "M-x profile-start".  That might show you a
> hint where the delay hides.
>

It appears that the delay gradually increases when it does go bad. At
the moment a rename is taking around 1 sec (same copy operation is virtually
instantaneous when emacs first started)

This (cpu report) was with moving 10 files
- command-execute                                                4937  99%
 - call-interactively                                            4937  99%
  - dired-do-rename                                              4844  97%
   - dired-do-create-files                                       4844  97%
    - dired-create-files                                         4763  96%
     - byte-code                                                 4728  95%
      - dired-rename-file                                        3510  70%
       - dired-rename-subdir                                     2276  45%
        - dired-fun-in-all-buffers                               1187  23%
         - dired-buffers-for-dir                                 1183  23%
            dired-in-this-tree                                     13   0%
       - dired-remove-file                                       1222  24%
        - dired-fun-in-all-buffers                               1222  24%
         - dired-buffers-for-dir                                 1186  23%
            dired-in-this-tree                                      4   0%
         + apply                                                   28   0%
      - dired-add-file                                           1214  24%
       - dired-fun-in-all-buffers                                1214  24%
          dired-buffers-for-dir                                  1184  23%
        + apply                                                    30   0%
     + dired-file-marker                                           35   0%
    + dired-mark-read-file-name                                    58   1%
      dired-get-marked-files                                       19   0%
    + mapcar                                                        4   0%
  + byte-code                                                      62   1%
  + minibuffer-complete                                            21   0%
  + execute-extended-command                                       10   0%
+ timer-event-handler                                               8   0%
+ redisplay_internal (C function)                                   4   0%
+ ...                                                               0   0%

so the delay appears spread across various routines? I did have a report with
the very long delay and I think it was similar[1] - certainly there wasn't
one obvious routine which was hogging the CPU. The system monitor shows
emacs at 100% of 1 cpu while it does the rename.

Robert
[1] unfortunately I forgot to save it when restarting to get a fresh
emacs :-(
-- 
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/