Btw, this mailing list thread might be related:
http://lists.kde.org/?l=kde&m=123607930707861&w=2

Ah, well, It was just a shot in the dark. What I do when this happens I copy a folder and paste it in the same place, wait a few seconds until the notification appears from the sys tray then click cancel, that makes it fast again.

ssri wrote:especially in directories with many subdirectories; the effect is most pronounced when navigating ntfs drives but it is seen in ext3 partitions just the same.

For me, dolphin slowed after I had a disk crash on my XFS external drive. (Not the first time, either; XFS, or the Maxtor device itself, doesn't handle loss-of-power dismounts gracefully.) Running xfs_repair created a lot of lost+found entries and, apparently in my case, a bunch of corrupted .directory files.

I had never looked at a .directory file, so I figured it was time. Here's one from a recently-created directory on the same XFS device:

[Dolphin]
Timestamp=2009,3,9,18,2,30
ViewMode=1

ViewMode=1 corresponds to enabling the "Details" view. If you have "Preview" enabled in a directory you get the directive "ShowPreview=true" as well. These seem innocuous enough, but storing a timestamp seems a bit bizarre to me since the underlying filesystem already knows the creation and last modification date of every directory. It makes me wonder whether the reconstruction of my XFS volume created inconsistencies between the filesystem timestamps and those stored by dolphin, and these inconsistencies caused dolphin to perform so poorly.

This filesystem has somewhat over 3,000 total entries, not a very large number at all. /usr alone on my system has over 170,000 entries.

For those having problems with thumbnails, does it help to remove $HOME/.thumbnails?

ssri wrote:especially in directories with many subdirectories; the effect is most pronounced when navigating ntfs drives but it is seen in ext3 partitions just the same.

For me, dolphin slowed after I had a disk crash on my XFS external drive. (Not the first time, either; XFS, or the Maxtor device itself, doesn't handle loss-of-power dismounts gracefully.) Running xfs_repair created a lot of lost+found entries and, apparently in my case, a bunch of corrupted .directory files.

I had never looked at a .directory file, so I figured it was time. Here's one from a recently-created directory on the same XFS device:

[Dolphin]
Timestamp=2009,3,9,18,2,30
ViewMode=1

ViewMode=1 corresponds to enabling the "Details" view. If you have "Preview" enabled in a directory you get the directive "ShowPreview=true" as well. These seem innocuous enough, but storing a timestamp seems a bit bizarre to me. After all, the underlying filesystem already knows the creation and last modification date of every directory. It makes me wonder whether the reconstruction of my XFS volume created inconsistencies between the filesystem timestamps and those stored by dolphin, and these inconsistencies caused dolphin to perform so poorly. Or, perhaps more simply, the files themselves were truncated or otherwise corrupted, and dolphin wasn't well-prepared to handle that eventuality. Sadly I didn't keep any of the .directory files from when dolphin performed poorly.

This filesystem has somewhat over 3,000 total entries, not a very large number at all. /usr alone on my system has over 170,000 entries.

For those having problems with thumbnails, does it help if you delete the contents of $HOME/.thumbnails?

May or may not be related, but if you have previews enabled it greatly slows the Dolphin down. Closing the preview pane on Ubuntu 8.10 solved my problem which mysteriously started a month ago (No it doesn't solve it, but it may lead to the answer and helps people move faster in the mean time).