Alignment is a performance issue.
As modern CPUs have minimum 32 bit data bus it reads for example 4 bytes with one access, always beginning with the last two bits zeroed.

Imagine you have following command reading a dword (dd):

mov eax,[buffer]

and buffer will start at address 0001:5551

This could result in worst case in two external memory access *:
0001:5550 (and throw the first byte)
0001:5554 (and throw 3 more bytes)

To avoid this, you could do align 4 which will always put buffer at an address divideable by 4 and add some extra space in memory structure.

A more common alignment is in "paragraphs" (16 bytes) or sometimes 200h for data in physical sectors on harddisc.

The point is, that alignment will also produce some waste of memory.
So it is a good idea to think of manual alignments for your variable section through moving data definitions in a proper way.


* in fact it is not the fully truth, architecture is more complicate and all memory access is controlled by a on chip memory controller which also feed and controls the internal caches (L1 and L2) which is structured in memory aligned portions. But my example is more easy to understand, I think.

format PE GUI

include 'win32a.inc'

struct DUMMY
  a dd ? ; offset 0
  b db ? ; offset 4
  align 4
  c dd ? ; offset 8 due to alignment
ends

section '.text' code readable executable

entry $
  xor eax,eax
  lea eax,[eax + DUMMY.c]
  ret
    

format PE GUI

include 'win32a.inc'

struc DUMMY
{
  .a dd ? ; offset 0
  .b db ? ; offset 4
  align 4
  .c dd ? ; offset 8 due to alignment
}

virtual at 0
  DUMMY DUMMY
  sizeof.DUMMY = $
end virtual

section '.text' code readable executable

entry $
  xor eax,eax
  lea eax,[eax + DUMMY.c]
  ret