I wrote this primarily in order to use it for writing D4775 with sensible member names.

@phosit I removed the emergency GC because the JS engine already does that when it hits 100%. I don't think there is anything to be gained by running it at 75%. That's just throwing away 25% of the JSContext ram.

@Stan No, i didn't change the logic from what it was before regarding overwriting m_ComponentsByInterface

Seems to me you overwrite m_ComponentDataByInterface with the latest constructed component.

Sorry, my mistake. I should have said that the interfaceId allows the wrapped version to be used seamlessly with the core logic. It does not enable using the compiled version with one entity and a wrapped version for another. It allows wrapping components in general, which then must be used by all entities. I agree that it seems logically suspicious, but I haven't thought of a way around it.

@phosit There are two containers because there are two id numbers per component type: ComponentTypeId and InterfaceId. InterfaceId can be thought of as component type category. If for example a mod provides a custom position component for some unit types that replacement component would have the same InterfaceId as the original position component but a different ComponentTypeId. This allows messages for the position component to be passed to either the original or the custom version.

@phosit
Components are stored in the ComponentDataHolder, which is used in ComponentDataByInterface.

No, sorry.

1. I agree but I don't know how to write it that way.
2. Unless I am misunderstanding you that is already the case.

@lyv Right, we cannot use player id here, only client id.

Change clientId to client in comment.

@vladislavbelov Ah, right.

Last commit was a mistake, this one reverts it.

@Stan Ok. I'm in the pacific time zone and usually available around noon.

This is where the tradeoff between animation lag and simulation lag is: under high load we must allow frame rate to drop in order to maintain simulation speed. I have a plan in mind for running dynamically budgeted slices between animation frames to keep frame rate up under less stressful situations but haven't prioritized it because if we can thread simulation there is no need for it.

I'm still fairly confused.

I'm now confident that my previous speculation was correct and that we don't have a problem here. @elexis thought that clientId isn't being sent with each command message but it is, it's just unlabeled.

I'm not entirely sure what you're referring to here

Tested by running two instances. Seemed to work fine, but I can't test a situation where multiple players are issuing commands on the same turn that way.

Elexus pointed out to me that this could break determinism via order of command processing. A deterministic sort of all commands each turn would be required to resolve it. I'm currently thinking the best option is to sort by the raw text of the commands by storing them in a priority queue.

Wrong diff command.

wrong diff command.

wrong diff command again.

wrong diff command?

Wrong diff command?

Don't know what the problem is here, I'm generating the diff the same way I always have...

Change host to clientId in log in NetClient.cpp.

Change host to clientId in log in NetClient.cpp.

Moved slice call to turn manager.

Hey all, sorry to take so long to get back to you.

No worries, do you need me to upload again?

Added time units (seconds, milliseconds) to variable names.

Space after if.

changed 1 to 1u, updated copyright year.

Removed m_LastGCTime, changed a comment, added gcInProgress.

What about the comment on timer_Time?

changed some int to u32

Didn't mean to submit yet, diff isn't ready, sorry.

Not a problem at all, I appreciate the time you put in to get it right :)

uint32_t changed to u32.

Ok, that's another task to add to the to-do list then. It should give a significant result in terms of graphics smoothness as well as freeing up some more time for simulation to run.

Since the patch is about timing i don't see how to test it without introducing a race condition.

uint32_t changed to u32

Add some includes, use timer_Time.

Reduce simulation thread load by ~10% (maybe a bit less, can't think of a way to test) and network traffic by 10-18%, depending on player APM. 500ms indeed sounds like too much. But 200 might have been an over-correction. The difference from 2 turns per second to 5 turns per second is ~1/3 second, but the difference between 5 and 4 is 1/20 second. I think this is small enough to not make a big difference.

Changed type of gcPressure to double, changed type of gcBytes and gcMaxBytes to uint32_t, as well as m_HeapGrowthBytesGCTrigger and m_LastGCBytes. Added some const. Edited some comments.

Slice runs fewer times because it's time budget is typically higher. The total amount of RAM consumed should remain the same.

Replaced the constant 200 with the variable turnLength in Simulation2.cpp. Edited comment.

Space after if.

Copyright year, trailing white space, comment format.

Use range based loop in graphics/mapWriter.cpp

No I haven't tested multiplayer.

Formatting, range based looping, avoid stack allocation in Game::IsFinished.

I haven't deeply read the code for source/lib/allocators/* or the code which uses them so I don't know.

changed range based loop to std::for_each in destructor.

@Stan some of it will be coming from avoiding unnecessary copying, passing by reference. The theoretical complexity cost of removing the capacity limit is negligible. I would want to do more runs and average them together before I trusted that number to mean anything beyond that it hasn't gotten any worse. But I'm too tired to do that right now.

@Stan %12.7 👍 (based off one run)

Hello @jprahman, thank you for your help! I think there is more performance to be found, some in network and some in SpiderMonkey GC. Hopefully some more in territory calculations. After those we may want to try multi-threading. A lagless TG might be possible :)

Added more tests, made ComponentDataHolder::Pools return a reference, renamed AllocFunc to ConstructFunc, use for_each in ComponentDataHolder::Destruct, use range based loop in ComponentManager::ResetState.

version control fail.

Changed uint_32 types for vector indices to size_t. Supposedly the type should be std::vector<std::byte*>>::size_type, but I haven't been able to get that to work.