And underground belt upgrades aren't bidirectional either.

@Max, you don't want to do that. The cost of the unaligned access of your double member (especially if it happens to cross a cache line boundary) is more expensive than the extra bandwidth used from padding.

Regarding optimisations, have you considered using database techniques to optimise out that huge annoyance that is Autosave? A large production database cannot afford to lock up for several minutes every few minutes to write everything to disk; if you use an approach like the redo log stuff in Orac...

I do agree with you that mrvn's table of waypoints idea sounds a lot like a n^2 problem. That's just space. Computationally, it's travelling salesman, which is NP. I'd hazard it's probably cheaper computationally and more effective to route within the coverage area instead of between explicit robop...

If that pointer is being accessed often, then it is probably in cache. That means the extra indirection itself is relatively cheap, especially if doing things that way results in code that generates more cache hits and lower overall cache misses. But it's still one extra memory region, taking up va...

Have the developers ever defined what they mean by "large bases" and "mega bases"? It would be useful to know (in terms of number of entities/factories/bots/belts) when reading about how these optimizations are tested and measured. Excellent point. Some people might think a rock...

I don't know your code of course, and I'm hampered because my experience is C not C++. Depending on the list and the type of removals, I'd wonder if you really need to delete them or can just mark them inactive. If a new entity gets placed on the map (or one gets removed), then yes the list needs t...

You guys are using... linked lists?... Why, oh why do you use linked lists? It is supposed to be common knowledge that in almost all situations even a straight vector is better. At the very least something like C++'s deque would be better. Tell me how you'd get: O(1) time to turn an entity on/off a...

Very many entities will be aware ahead of time when they will next need to do work. An assembler doesn't need to do a thing for X ticks until its craft is done. An inserter is doing nothing for Y ticks until its swing is complete. Etc. Even an inserter hovering over a belt can predict to some degre...

A linked list of multiply-inheriting classes? I'd have expected an array of structs. I'm surprised to. I'd have expected C++ to handle virtual function calls and inheritance at compile-time, but apparently things are setup so that some of the required class structure isn't known until run-time? Thi...

A linked list of multiply-inheriting classes? I'd have expected an array of structs.

Let's imagine the following scenario: Bots are removing/placing rails which changes the rail network causing rerouting. On your beefy 8-core machine the recalculation happens immediately, a train repaths and goes his merry way. A bot places another rail piece. On your friend's lowly 2-core machine,...

Since this magic free copying ability doesn't even exist, you would actually be adding more work so saving would be more painful overall. I never said the fast copy would be free, I said it would be many times faster than the existing copy, allowing the pause time to be reduced by that same factor,...

I'm always annoyed when trying to do something and the saving dialog pops up. And the more you play the larger the problem becomes because saving takes longer on larger factories. Why not save in the background in a separate thread and let the game keep running? "All" this would need to d...

Some thoughts on save performance. Firstly, you mentioned a few weeks ago that you were looking into optimizing data structures for item stacks to make certain frequent operations faster. Similar updates may benefit save performance as it needs to go through a lot of data structures. Secondly, you m...

Yet another reason of choosing other hash function: We have only 64bit version of the game, and in 64bit process the CPU can hold 64bits at once in a single register. So by choosing other 64bit hash function you will still be able to compare hash values like numbers (not arrays). This. An algorithm...

With the T-ends on the rail indicators, they don't really need to be different colors. What is important is the clarity of separation between blocks. Another suggestion for the graphic is to have a rectangular box of the same width as the T you showed, again all the same color. Disagree. Let's take...

Yes, but you may want to colour all those 2's as if they're adjacent for clarity. And such preferences may lead to non-planar problems which aren't 4-colourable.

I spent also 780h into the game. And I like the changes too. But speaking making things easier for new players and inventory. I hate the group function. I'm searching so many time for an item in the inventory. It's getting worse if you play with mods. So why we do have registers in the crafting are...

With the quickbar changes, this opens up the possibility for blueprints to not be items. Having blueprints in your quickbar is handy, they have no business being in your inventory as it should always be faster to pick blueprints from the blueprint manager than from your inventory.