SPI with DMA on XMEGA

I have the XMEGA256A3U and sending out 1024 bytes over a SPI bus. Before sending and after the send command I switch an output port. The difference between port high and low is the time it takes to send out those bytes.
The time it takes (depending of cource on the frequency) is about 400µsec when I just send it out with "MSPIout_D1(@Buf,Sizeof(Buf));
Now I added the "MSPIDMA_OUT_D1 = DMAch0;" to the defines to send it out with DMA support. The time it takes now is about 1000µsec.

I know what DMA is and how it works with a PC system, but my question is, if I understand it right for the XMEGA and AVRCO:
- I can imagine that sending out with DMA takes longer because of handling issues and because it has to wait for free slots to access the ram. But at the other side it does occupy the CPU much less because it is done while the CPU is performing other tasks: so spending less cpu runtime.
- When programming the send command with DMA, the code behind the command is only executed after the finishing of data sending with DMA. So it doesn't help you because it doesn't execute other code at the moment, or does it automatic do a 'shedule' to other processes at the mean time?

Thanks for some more information.

Thanks Rolf.
Cause the posibility of interruption is not an issue for me, I better don't use DMA: it's faster

So the DMA controller is now configurated to transfer for instance 1000 bytes automatic without interference of the CPU. If the CPU would not wait for completion and directly go further, we would gain cpu run time, but at a slower transfer rate...
Especially for controlling a display, it would be great. Video ram, defined in AVR ram, can be transferred to the display without losing much cpu run time. Only an interrupt is needed to flag completion and set back the display chip select. The rate of transfer is not that important, except for the tearing effect when using moving pictures