It could be that the Relative ID Master is off-network for you. When you create new Computer objects (join the domain, I'm assuming you don't pre-create your objects), it has to go to the RID master. If the DC holding that role is off network for you, it could take a long time to round-trip.
Alternately, it could be that your AD tree doesn't have a Site declared for your satellite network. Therefore, domained machines keep referencing Global Catalog servers not local to you because no site boundary was declared for some reason. You might be able to look that one up yourselves (but not make changes) through the AD Sites MMC tool.
A pair of (very possibly wrong) thoughts.
Edit: Everything? That sounds a lot like the Security checking is horribly slow for some reason. SID lookups and the like are horribly slow. That makes it sound a lot like you're going across the WAN for those lookups when you shouldn't have to. Incorrect sites, or perhaps your local DC doesn't have GC.
How it works is like this:
- Visual Studio accesses a DLL
- The OS then determines if Visual Studio can access that DLL at all
- The User's security token, given to the user a login and contains all their group memberships as well as their direct security identifiers, is then referenced
- The OS checks the security details of that DLL, finding a list of SIDs
- The OS then resolves those SIDs against the Domain
- The domain is probably in Australia for you
- The OS checks the security principles against the user's security token
- The OS grants access
Wash, rinse, repeat for every file accessed. The workstation should keep a cache of SIDs, but VisualStudio opens up a metric bajillion of files which may over-run the cache.
You can do a very rough check of domain lookup speeds by right-clicking on any NTFS file or directory and going to Security, entering a real user, and clicking the Lookup User button. How fast that goes should scale with the speeds you're experiencing between your domained/non-domained workstations.