Frame rate drop with high number of ships per system

[clausimu]

I just did a test with increasing the amount of trading ships (TradeShips.lua) per system. Even just ~600 ships in the system give me pretty significant lag times in the game. Is that a game engine limitation or a matter of the lua script itself? I think increasing traffic (at least around key points of a system i.e. starports) would increase the fun (at least for me). Having to wait in line to be able to dock etc. would increase immersion (again, at least for me). But 600 ships in a system like Sol still don't cause a lot of traffic - but seem to push the game past its limits. Is that true?

Thanks,
Claudius

[FluffyFreak]

Can you share the modified TradeShips.lua? I would really like to have more traffic in each system but there are issues with docking and not really enough space stations in each system.

I started a thread about it some time ago if you'd like to discuss actually making systems busier in that one and the slowdown bug in this one :)

[clausimu]

I didn't do anything fancy with the existing TradeShips.lua. All I did was replace line 382:

num_trade_ships = num_trade_ships * (Engine.rand:Number(0.25, 1) + Engine.rand:Number(0.25, 1))

with

num_trade_ships = num_trade_ships * (Engine.rand:Number(0.25, 1) + Engine.rand:Number(0.25, 1)) * 20
Comms.ImportantMessage(string.format('There are %s ships with you in this system!', tostring(num_trade_ships)))

If you start at New Hope the game takes a long time to get up and running (about 10 seconds until you see the starport). Then the frame rate is around 3 fps with intermittent jumps to ~15 fps. To launch you have to wait again 4 seconds. Flying works. After jumping to Sol - 4 second wait for the new system to load. There it is ~8 fps.

I am using the 64-bit Linux build from Jan 10. My computer is not top of the line (Laptop with 8 GB RAM, 8-core i7 @ 2 GHz, ATI Radeon 5000M series), but I usually don't have any frame rate issues with Pioneer.

If there is anything I can do to help debug, let me know. I won't be much help with the game core. Also, my coding skills with lua are beginner level. I'm mostly a Python guy.

[FluffyFreak]

Having just taken a quick look at it I think multiplying by 20 might be ambitious!

There's nothing clearly running a lot slower in the profile I took but each and every one of those ships is fully simulated. There are no shortcuts for ships you cannot see for example, all of them are in orbits, docked, accelerating/decelerating and doing all of the other things ships can do. I see more Lua calls than usual in the profile but there's not a great deal of scope of optimising those if it really is core Lua functionality.

[clausimu]

The multiplication by 20 just resulted in ~600 - 700 ships in the system though. Is that too many for the game to handle? I guess in that case we will need some shortcuts to only fully simulate ships within x-distance of the player. I figure if I am approaching a starport on earth for example, I really don't need ships fully simulated approaching Pluto. Although for immersion there should be indications that ships actually exist outside my range of visibility.

Would that be something for the lua script to handle (check for distance from player to spawn and remove ships) - or something for the core engine?

[DraQ]

Could we have "tick length" adjusted for ships based on their proximity to other objects and velocity in their preferred frame of reference?

A ship in combat or maneuvering above spaceport may need frequent updates, but one in transit many AU from the nearest macroscopic bit of matter can afford being 'woken' only once every few game h.

[FluffyFreak]

If, and it might be quite a big "if" as we deliberately try to keep timesteps small even when running at reduced framerates, then the place to look would be `Space::TimeStep`.

Profile it first to see what's taking so long and then see if, for example, it's a specific subsystem and can we optimise that single point. Or is it just a lot of work being done all over the place then can we do it less often? Perhaps spread the update frequency of ships across updates, so if we've got 100 ships can we do just 10 per update until they're all done then start again at the beginning?

EDIT:
After some investigation it seems like one of the culprits is the "Animation::Interpolate()", it takes a lot of time so just seeing what if anything can be done about it.
Another one is in "Ship::UpdateAlertState()" where it gets the nearby bodies, I'm going to cache that for each ship I think and just update it once per-second, seems to reduce the number of (quite expensive) calls from nearly 2000 down to... 3, which is a lot better.

So there are some things to improve upon :)

[FluffyFreak]

Ok, there's a pull request with some optimisations in it that people can try out if they're willing to use Git to checkout the branch and compile there own version.

There would still be a lot of work required before we could support that many ships in the regular game though because just saving it takes 10's of seconds and creates save files anywhere between 24MB and 35MB!

Actually simulating the ships doesn't take much processing time at all, I've got profiles of it doing over 2000 ships per-frame (due to repeated physics step interations) where they account for less than 3% of the time. Good news I suppose :)

[laarmen]

I'm guessing one of the culprits of the saving lag is the equipment. It is at least linear to the amound of cargo each ship holds! One could write a TradeShipEquipSet to pack up the cargo data instead of holding a reference for each Hydrogen ton in the haul.