I am considering to allocate most persistent data of my ECS framework on a one-frame allocator.

To extend their life to exist on > 1 frame, I will need to copy it to another buffer.

Initialization  I create Buffer X and Y.  Each has 50-300MB.

• 1st timestep : every Entity / Components will use buffer X to allocate.
• 1st-end : copy every Entity/Component that are not marked as deleted to buffer Y, clear X.
• 2st timestep : every Entity / Components will use buffer Y to allocate.
• 2st-end : copy every Entity/Component that are not marked as deleted to buffer X, clear Y.  ...

Advantage

• almost 0 fragmentation cost, pool is not needed anymore
• very low cache miss in game-logic

Disadvantage

• high cost of memory swapping (X<-->Y 50-300 MB every timestep)
• Reason : computer can read or write memory at 10 GB/s = 170 MB/timestep
• (reference : https://stackoverflow.com/questions/25827416/ )
• (minor) pointer become invalidated, I must use ID instead

Note: Luckily, every components are POD (plain old data = no pointer as field).

After some draft, it strongly believe it is possible to implement.

Question

• Does it sound bad?  Is it a good practice / technique?
• Is "ping-pong buffer" a correct name of this technique?  What are other names?

I tried doing something similar to this 10-12 years ago when I was trying my hand at a Liero clone, but with N stages/copies/whatever (ie 5). The idea was basically to store a complete copy of the game state up to N frames back. This way I thought I could back up and re-run the simulation when an old network packet arrived. The reason I wanted to do it that way is that it (Liero that is) is a rather fast paced action game, with thousands if not millions of objects and destructible terrain, where butterfly effects can potentially be a giant problem, while back then we also had much crappier connections than we do now.

Anyway, my conclusion was basically what swiftcoder said, memory bandwidth sucks. Back then we had something like 1-2gb/s, which I thought would give me something like 20MB/frame, but I didn't initially realize that it was 20MB spread across the entire frame, not a quick action at the beginning of the frame. In short, the copying alone ate every last slice of juice my high end P4 system had to offer at the time.

Thank a lot, swiftcoder, DvDmanDT and ApochPiQ. 

Your valuable knowledge save me several working days.