I'm having the same slowness issues, and I'm pretty sure the faults are in MC9's hands..
Setup:
server --> win2k server, ~500gb disks, 512mb ram, dual p3-1k, gigabit network
client--> winxp pro, 1gb ram, gigabit network, p4-2.8k, gigabit network
The network isn't in the way, I've done 30MBps transfers in testing before between the two machines (generated from ram, the disks aren't that fast). The disks the majority of my files are on can sustain 3MBps or better (e.g., copying files with explorer, verified with network analyzer)
In testing with iTunes and changing tag versions of files that didn't previously have 2.x tags, I've seen iTunes hit the 4-5MBps range, on both reading and writing, again verified at the network level.
Now with MC9 (290 is my latest) I'm lucky to see 1MBps. utilization on both machines is near zero, and while the disk io on the server is measureable, it's not the limiting factor.
Also.. From what I can tell, the way that MC9 writes 2.x tags (on mp3 files), it rewrites the entire file when there is a tag change. It doesn't always seem to do this, but it does it more often than other programs performing similar actions..
I can understand the safety reasons in copying the entire file when a tag is first prepended to a file, but there should be an additional buffer built in at that point in time to accomidate future tag changes (re: ID3 recomendations, id3.org). Is MC9 including a buffer when it adds / alters a tag? My gut answer given it's behavior is either no, or one that is too small. The recomendation is to round up to the next block size (or double the current size again rounded, whichever is greater).
Does anyone have any thoughts? I'd prefer to continue to use MC9, but given the size of my collection and the number of >100MB mp3's I have, I'm really not that patient when I make tag changes.. I'm implying that other applications are faster.
Thanks,
Peter