Depends what you are trying to achieve! An FPS camera for example can be treated as an inverted world matrix mostly.

Third person view might be better as a look at matrix construction for simplicity or might use quaternions to prevent gimbal lock.

Then again I am sure Mike can add a lot more about the subject after writing Thief: Deadly Shadows camera!

But I think you should add what you are trying to achieve as currently the question seems to be very general and may have different approaches for different goals.

I did a little bit of web research on the subject and basically came up with nothing!

But, all is not lost - I can talk a little bit about your question.

Most games do pretty much what the GCC4 source code does - create three transforms for the World, View, and Projection and concatenate them to take vertices from a particular object in the world and transform them to a spot on the screen, with depth information so the renderer can draw things over each other.

Calculating these efficiently has more to do with keeping values constant from frame to frame if you can. For example, it is unlikely that the projection matrix will change - since that is calculated from things like your screen width and height, and the shape of your camera view frustum.

The view matrix will change any time the camera moves - which is pretty much every single frame in most games.

The world matrix will change when the object you are rendering moves in the world - which actually stays pretty constant for most objects in most games.

Actually calculating any one of the above transform matrices is pretty efficient - given a position in the world and your typical Euler angles for rotation, which you likely loaded from your game level file - so if your game is bound on calculating these things you are WAY ahead of the rest of us!

One last note - it can be really enticing to roll up your sleeves and try to make absolutely every line of code in your game as efficient as possible, but as Rez said before only about 10-15% of your code is really worth optimizing - the rest can be pretty pokey, since it just doesn't get run that much per frame.

I hope that helps!