I would say no, that is not normal. For example, I just tried all of the operations you mentioned on the FAA Aircraft Registration database, that has over 300,000 records and 46 fields. At most they took a second or two, no beachballs for any of these operations.
As I mentioned in a post recently, the Data Sheet can be slow for operations like inserting and deleting fields if there are a lot of visible fields. I try to keep the number of visible fields below around 50. If the database has more than 50 fields I will usually only have some of the fields visible. The delays are caused by Apple’s code and there is nothing I can do other than writing a ton of new code to completely replace Apple’s grid code, which would have a bunch of other drawbacks, as I explained in the previous post.
One thing that can be slow is if a form has a text list or matrix linked to the database and the data sheet is also open. This is kind of like having two data sheets open. It’s best to avoid this and have only one at a time. Also, Panorama X will definitely slow down if you have a bunch of forms open that display a lot of data items. If possible, you’ll get better performance if you only use one or two at a time.
I think the “biggest” database I have has 80 procedures, but the View Organizer runs instantaneously, and so does saving. The View Organizer is not going to care about the number of records or fields. I’ve never seen any delays in the View Organizer, and wouldn’t expect to (and I use this wizard all the time).
I did quite a bit of work on performance issues in the spring. If you go back and look at the release notes you’ll see comments about improved search speed, lookup speed, and other areas. I did a fair amount of profiling at that time and I think the low-hanging fruit has been picked – I’m not expecting any further across the board speed improvements in Panorama X.