I moved several a few ten thousands of mails that mailfilter agent was filtering to a wrong folder due to a wrong filter rule to the right folder. I did it in several steps and made the following observations:

Reproducible: Always

Steps to Reproduce:
1. Have a local maildir folder with about 60000 mails as source
2. Have a local maildir folder with about 12000 mails as destination.
3. Move about 20000 or 30000 of mails from source to destinations in three or four steps
   - Select first mail
   - Select last mail you want to move with shift click
   - Drag to other folder and select move.

Do it in these three different ways:
1. Have source folder in usual threading view by activity.
2. Have source folder in flat date view.
3. Immediately switch to another folder after you started the move operation.

Actual Results:  
The results of the three different ways as I got them:
1. First akonadiserver and maildir agent are very active, as well as mysql. Bursts of mysql activity (with recent Akonadi 1.13 branch git with MySQL optimizazions as of today – didn´t change in last time). Then kmail at 100%. Displaying progress. Taking several seconds for each 10 mails according to progress report. Takes ages!
2. Similar. Maybe a bit better.
3. Akonadiserver and maildir agent active. Akonadiserver writing, maildir agent reading. Then strong bursts of MySQL up to 250% of CPU usage for a minute or more. Then move done. No significant CPU activity of KMail. Move is *way* faster.

Expected Results:  
Even with source folder open move is *fast*.

Maybe be KMail using some kind of delayed updates while clearly showing folder message list view is in process of changing. Don´t update for every since mail that is being moved.

Using kmail 4.14.2 but self compiled kdepimlibs, kdepim-runtime and akonadi server as 24 February (with akonadi server having had no changes since then.