Look at this screenshot below and if you can follow this I guarantee for the few extra seconds it takes to make, you will save yourself HOURS and HOURS of compiling time in the future, and save yourself a ton of FPS. It is one of the simplest methods you could ever follow, and I can show you how much this method saves...
On the left are 2 squares that look absolutely identical. On the right you can see they are made differently. One saves lots of compile time and fps as well as texture memory, the other doesn't. Can you tell which is which and why?

Box 1 is made using the clipping tool to trim off the edges so the walls align, this means there is no leaks and we have reduced the amount of visibly textured units.
Each block is 128x128 and the walls are 16 units thick. So the inner textured square will be 96x96. Easy so far..
When you texture box 1 you will use a 128x128 texture to cover each of the external walls. This will be exactly the same for box 2, so there is no saving there. The benefits can be seen when it comes to texturing inside the box...
In box 1 you will need to texture each of the four inner walls with a texture of 96units wide, by 128 units deep. The angled joins are not textured at all as they are not visible and do not count towards vis, so they are not in the vis compiler, and thus do not get rendered in the game.
When you come to texture box 2's inners walls it's a different story.....

Now you can see that there are 2 overlapping walls. This causes a problem, because now when you texture the inside you have 2 walls that will be textured 96x128, as in the first example, but the other 2 walls will be textured 128x128, and although these walls cannot be seen they will be compiled and drawn, as they have a texture on them.
So in this little 128x128 box room with no wall or floor, we have a total unit texturing of
Box 1 = ((128x128)x4)+((96x128)x4) = 114688 textured, compiled and rendered units
VS
Box 2 = ((128x128)x6)+((96x128)x2) = 122880 textured, compiled and rendered units.
So in this little example we have saved the engine 6.66666*% of it's workload. While that does not seem a lot, it does make a hell of a difference as you work your way through the map. This is one of the simplest ways to make sure you don't run into issues like you have. Working wisely as you go saves you so much time trying to correct errors at the end. Prevention is always better than trying to cure, and so much less work....
Making sure your brushwork is correct means you can get a much more streamlined map. There are lots of other issues with vis that you can learn, but start mapping right, and all the rest will be childs play.
With the images you have posted above, and as people have already mentioned, you have way too much visible at one time, the engine is having a fit trying to cope. what you need to do is make it so less is visible at any one time, hint brushes will never work in that sort of room, because there is no portals/corridors to use them in. Make your dropship in it's own confined piece of the dock if you do not want to lower the size of th dock itself. Unfortunately I can't give you any examples of what to do as I only have the source hammer editor installed now, i hvae given up trying to learn HL1 mapping when it is going to dissapear in a year or two, much better for me to learn the new source mapping way ready for NS2...