There's not much difference between the two approaches. If you look, both have a computational complexity that grows linearly with the number of tiles. The square arrangement leaves y unchanged per row (assuming you go line-by-line, left-to-right, top-to-bottom), so there is slightly less computation per tile, but that complexity is dwarfed by any per pixel operations you may want to do. These days, per pixel operations can be done by graphics processing units using a high-level shader language (it makes sense to do 2d games with 3d hardware these days) as specialized hardware will outperform software rendering.
If you are doing animation and going old school (no 3d hardware) you'll want to use two buffers and draw to the second buffer and then, when done rendering the the frame, flip. If you write your code in a modular way, e.g.:
Draw Frame
Draw Map
Update Sprites
Draw UI
Draw Pointer
Start with a "best and quick effort" first, using best practices like encapsulation and design patterns that abstract the method (e.g. zig-zag or diamond) - a great chance to use the strategy pattern. You can figure out where your bottleneck is by timing each action and then going back and optimizing. After your code tells you where the problems are, then change the implementation.