Event Timeline
As seen here, ParseTerrain is ~20 ms faster. Total map gen time increased, which may or may not be due to a slighly older svn used for testing the unmodified system. exportTerrainTextures is also negligibly faster. Of course, the end result was same and there is no oos risk.
New system
Total map generation time: 42.029s.
Total entities: 7666, Terrain entities: 6287, Textures: 15.
TIMER| ParseTerrain: 39.8779 ms
Current system
Total map generation time: 40.376s.
Total entities: 7666, Terrain entities: 6287, Textures: 15.
TIMER| ParseTerrain: 59.5032 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
New system
Total map generation time: 40.898s.
Total entities: 7551, Terrain entities: 6177, Textures: 15.
TIMER| ParseTerrain: 44.1158 ms
Current system
Total map generation time: 40.394s.
Total entities: 7551, Terrain entities: 6177, Textures: 15.
TIMER| ParseTerrain: 60.4342 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Current system
Total map generation time: 35.909s.
Total entities: 7551, Terrain entities: 6177, Textures: 15.
exportTerrainTextures: 0.005 s
TIMER| ParseTerrain: 58.872 ms
TIMER| ParseEntities: 4.91293 s
New system
Total map generation time: 36.125s.
Total entities: 7551, Terrain entities: 6177, Textures: 15.
exportTerrainTextures: 0.003 s
TIMER| ParseTerrain: 39.207 ms
TIMER| ParseEntities: 5.00326 s
I should note, that this would also use less memory. Which maybe a good thing or a bad thing. Now, there can only be max 256 textures and 256 priorities.
Well saving 20ms once per loading screen is indeed negligible, but I appreciate the correct investigation.
Limiting from 65536 to 256 textures at most seems like an unnegligible restriction if we think about an ideal engine.
Better check the greatest problems to tackle first (#5011) - or testing whether serializing the entire terrain is making things more performant - or making rmgen not pass any entity in exportMap for rejoiners.