When your compile takes a silly amount of time, it is likely the VVIS step that is working the longest. VVIS takes every corner of every vis portal (the 'sides' of a visleaf), and checks to see which corners of every other portal it can see. Naturally, if you have a lot of places where lots of portals can see other portals, it is going to take a very long time to calculate.
Before you start to optimise your map, you should perform a VBSP-only compile, with no VVIS or VRAD steps. The VBSP step creates the vis portals that VVIS calculates, and will take a few seconds even on very large and detailed maps. When it's complete, open the map's portal file, using the option in Hammer's menu. This will display all of the vis portals as blue lines in Hammer's 3D viewport. Look for places where there are too many vis portals, and for open spaces where a lot of vis portals can see each other (for example, the sky over your buildings). Use the methods in the web site that iiboharz linked to reduce them and limit visibility between them.
If you have an oddly-shaped building that is large enough to obscure a player's vision of the things it conceals, and it is causing unavoidable ugly-looking visleaves, don't worry about it too much. The object of vis opt is not to make every visleaf square and large, but to limit what is visible to the player at once.
Hammer's compile console freezes up during compile, so it's hard to see what is going on. If you use a third-party compiler like
CompilePalX, the compile progress will be shown in real time.