Currently, project loading and saving runs in the main thread, which means that it will do just what you experience, it will freeze the GUI until it is done. This is not normally an issue, however it can be on a SMB share. We're already scheduling several concurrent reads form a worker thread pool and use some buffering tricks to hide at least some of the latencies, but we're not unable to work around some. On local files, the buffer cache takes care of the greatest evil, over SMB, it does not.
A couple of wxWidgets calls do several stat calls and several small reads (this used to be in particular an issue for plugin loading which are zipped, and was the reason why we've implemented an unzip-from-memory-buffer thingie -- wxWidgets would otherwise read the files in chunks of 300-400 bytes at a time, you can imagine what that means over SMB). Each stat adds at least 15-20 milliseconds over SMB (often more), so if you do a few thousand of them, it quickly sums up. Some we can work around, some we have not found a solution yet.
Code completion should not normally make any significant difference other than causing more network traffic and more seeks on the SMB server, as code completion does not run in the main thread.
Moving project loading to a separate thread may be a solution, however I would be very reluctant about putting saving into a separate thread, for it bears great evil. Note that this will not make loading any faster, of course, just the GUI will be more responsive, which makes it somewhat less annoying.