[LevelEditor] Extreme optimizations loading LevelData - #316
Conversation
optimized loading it through Dictionaries and not using FirstOrDefault() on a *180,000* long list of entities time goes from like 25 minutes to 1 minute on average for deathstar2_01, it went from 42:55 to 1:15
|
|
||
| public bool IsSimulationRunning => simulation != null; | ||
| public IEnumerable<Entities.Entity> Entities | ||
| public List<Entities.Entity> Entities |
There was a problem hiding this comment.
why did u decide to use a list
There was a problem hiding this comment.
idr, can probably be reverted. the performance chance would be minimal anyways because this new method has this whole part only takes like 0.6 seconds to do
| } | ||
|
|
||
| public List<Entities.Entity> FinalEntities; | ||
| public Dictionary<Guid, int> entitiesIndexes = new Dictionary<Guid, int>(); |
There was a problem hiding this comment.
i would just make this a Dictionary<Guid, Entity> tho idk if the instanceguid is even unique for all entities, probably best to have it be some hash of the class and file guid. but yeah with this u dont need the list shit and hashset for entities, still need the referenceObjects one, tho idk for what thats used
There was a problem hiding this comment.
in deathstar_01, theres only about 5k unique instanceguids with a total of 181k entities.
how the old way did it was FirstOrDefault(), meaning it would just iterate through them, so the dictionary takes the first instance of that and sets it to the index and throws out any ones after that to match its old behavior.
There was a problem hiding this comment.
yeah i know how it was before, its just the way u did it seems to be over complicated. Also i think that its not correct as well since iirc 2 entities can have the same instance guid but are not the same, u should probably check for the classguid and fileguid to get a proper unique identifier
There was a problem hiding this comment.
if the old code didnt do that why should we now? theres got to have been a reason it just threw away sequential objects
There was a problem hiding this comment.
its been a while since i looked at that, but iirc it was a bug with entities loaded from different blueprints, which got fixed when using the file and class guid instead of the instance guid
There was a problem hiding this comment.
why wasnt this resolved already then? i saw in your build it had something similar to this
2 participants
optimized loading it through Dictionaries and not using FirstOrDefault()
on a 180,000 long list of entities time goes from like 25 minutes to 1 minute on average
for deathstar2_01, it went from 42:55 to 1:15