It seems that Picard has a long history of terrible performance when it comes to saving files, as evidenced by the number of issues on this tracker that mention how the UI locks up, etc.  It seems that all the existing tickets are treating it as a UI problem, whereas I suspect that it has more to do with Picard's file I/O logic.

For years I too have been thinking that the problem is with Picard's UI threading code (or lack thereof), but today, after upgrading to version 2.2.2, it got so bad that after waiting over half an hour for it to finish saving only about 50 files, I finally decided to open my task manager and try to figure out what's going on.

What I saw in Task Manager's "Performance > Disk" section can only be described as insane: 100% disk activity for tens of minutes, without any perceptible progress in terms of moving/saving the actual files.  This leads me to believe that the problem has more to do with Picard's low-level file handling logic than with any UI code.

In my first Picard session today after upgrading, I was attempting to save 5 albums from one artist (about 50 .ogg and .mp3 files totaling about 450 MB in size).  The first album (consisting of 8 mp3 files / 84MB total) took almost 5 minutes to save, then the whole process hung for at least 15 minutes without any progress whatsoever, yet somehow still using up 100% of the HDD cycles all throughout.  The other 4 albums (these were all in .ogg format, in case that makes a difference) took at least half an hour to complete.  Unfortunately I didn't have logging enabled in Picard and it didn't occur to me to save the "Activity History" before exiting the program, but I created a recursive directory listing that shows the layout and sizes of the files on disk after they were saved, in case that helps (see the Session1 - saved files.txt attachment).

The other 3 attachments pertain to my second Picard session today, in which I tried saving only 2 albums (26 mp3-only files / about 280M total).  It still took about 10 minutes, with 100% disk I/O throughout.

In full disclosure, I keep my music collection on the slower of my 2 drives (the 5400rpm HDD), but it still shouldn't have to take anywhere near this long to save a handful of files.  Also, I'm reasonably sure that this disk usage pattern wasn't caused by any other applications running on my system, because the disk utilization returned to normal as soon as Picard finished saving the files (both times).  It's hard to fathom how this application is able to legitimately generate so much file system activity while making so little progress, unless there is a serious bug here.

To summarize, I think the problem has to do with how Picard handles moving the files or saves id3 tags / cover art into the files.