Improved internal belt model

[HomerSimpson]

I've watched the stream by Arumba and noticed that belts are currently the bottleneck in Factorio.
So I've come up with a new model:

The main idea is to handle whole belt sections of one belt type as 'one object', so each tile of belt just contains a pointer to that object.
[Two objects to be exact, one for each side of the belt]
The object representing the belt section consists of an array, where each element represents a 'slot' on the belt.
[This means that each tile would have a fixed capacity (e.g. 8 items)]
[Why an array? Because random access is needed for inserters etc.]
The object also contains a start index, which is the index of the first 'item slot' of the belt section.
When the belt is moving, no items in the array are actually getting moved, only the start index is looped around through the array.
[This means the belt is always moving, 'not moving items' when the belt is full need to be handled differently]
So when the belt is full, the items that are backing up need to move backwards in the array.
As long as all items backing up are of the same type (e.g. iron plate), you can just take the first iron plate and put it at the end, which is just the same as all items moving one space.
[Since usually all items on one side of a belt are of the same type, that assumption is quite valid]
To allow different types of items on the same side of the belt, this gets just a little more complex (following in blue):


Lets look at the following belt thats backed up (R is for iron plate and C is for copper plate)
RRRCRRCC
123456789
instead of just taking the first item and putting it at the end, the object now needs to maintain the order of the items on the belt.
So to move all items one space back, R at position 1 gets moved to 4, C at 4 gets moved to 5, R at 5 gets moved to 8 and C at 8 gets moved to the end.
The positions of the transitions can be saved in a list.
Since this will almost never happen (each item type almost always has its own side of a belt), it doesn't matter so much that it is not the most efficient, I don't even think there would be a better way.


So what happens if you remove one tile of the belt section or add one?
Everytime the belt section changes the array might need to be reallocated.
The array could use similar size management as the std::vector class to adress that issue or the sections could have a max. length.

Inserters, side loading etc.:
Since all 'slots' can be accessed directly, they can easily work with the model.

Circuit Network:
Circuit Networks on belts propably wouldn't work efficiently, but for example a seperate belt type just for detecting belt contents would be useful or just an integration into splitters.

Conclusion

Pros:
-random access
-fixed belt capacity
-extremely efficient, the length of a belt and the amount of items on it do not effect performance
[a moving full belt over 2000 tiles would take as much CPU as a single tile of belt]
-loss of belt compression? never again! [the capacity of a belt would be fixed]

Cons:
-belt movement needs to be synchronized
-belts that are not moving and having different item types on it would be quite inefficient
-when editing belt sections a lot of copying needs to be done (a maximum length of the internal sections would be useful)


Questions/Feedback?

[hoho]

The main idea is to handle whole belt sections of one belt type as 'one object', so each tile of belt just contains a pointer to that object.

Devs talked about something roughly similar a few weeks ago in FFF:
https://www.factorio.com/blog/post/fff-148

[ssilk]

I think we're too far away from discussing such questions. It's as I would give a chirurgeon tips how to surge hearts.