The question is a bit arbitrary, because rendering efficiency is tied strongly to whichever drawing library you’re using. Beyond that, is is also a pretty big memory versus processing dilemma. If you cache the current viewport or the entire map, you’re going to have to store those (possibly massive) images in memory, whereas a tile-based approach is storing a few small images in memory and just instancing them when drawing them individually. As far as memory is concerned, the tile-based approach is significantly superior.
Now, in terms of processing time, it matters significantly on how your drawing library handles clipping in this case. Drawing the viewport image or just a translation of the entire map composite may be close to the same speeds, depending on how it handles image referencing, blitting, and clipping of the final image. If it uses hardware acceleration, it helps to know how it sends the final image being drawn to the graphics card.
If you want a VERY efficient system, you could even implement some sort of “dirty-region” setup that many older games used, as well as most modern GUI environments. This is a nice learning exercise, but I’m not going to go into it too much.
Finally, you need to think about your target hardware (whether or not you’re using software drawing, hardware will refer to the amount of main memory available, speed and availability of the CPU, graphics memory available, GPU capabilities, etc.) This is an extremely easy thing for even a CPU to rasterize, which means all three options are probably thousands of times faster than you would ever need to worry about. As a result, I would personally recommend taking option #3 because it’s the easiest to implement. It may be potentially the slowest (but even that is fairly easy to mitigate if you use a hardware-accelerated rendering library like OpenGL or Direct3D) but you really don’t need to be worried about that, anyway.