Does a time increment that takes 5 minutes to calculate depend on you cpu?

[leonidas1283 (OP)]

Does a time increment that takes 5 minutes to calculate depend on you cpu?

[Profugo Barbatus]

I don't think this really has anything to do with C#, but it can be awnsered regardless. The current biggest throttle point by far for Aurora is that everything is saved and loaded directly to the database, every time, without really living in memory. Your CPU has very little to do with the throttle, its all about disk access. Using an SSD or a RAMdisk can help, but its still a large number of operations that have to be performed just to update a fleets position, or a planets position. CPU centric operations like AI decisions, or damage/detection/combat calculations are a far smaller part of the turns right now.

C# heavily cuts into this by keeping content in memory when possible, cutting out all those save/load operations that are constantly being performed. Steve's already posted some preliminary numbers showing significant increases.

[Odin]

To add more, the game is written on a dead ancient language called visual basic 6.0 (from 1998) and the database is in access from the same age, you can't expect good performance with those premises.
The new version of aurora is written in c# and the database will be in sqlite, wich is faster than access.

To avoid slow down you should not put NPR at the start of the game and asteroid orbital movements. If you are trying to save your game from slowing you can try to disable planet orbital movements.

[sloanjh]

Two things:

1) I just made a "C# Aurora v0.x Questions" thread: http://aurora2.pentarch.org/index.php?topic=10097.0

Going forward, could everyone please put questions like this one in that thread?  If we don't, then Steve's posts will age off the front page VERY quickly, which I don't think any of us want.

2) Several (maybe 5-7) years ago Steve made a major performance change so that the DB is only hit at the start and at the end of movement.  IIRC that solved most of the disk I/O bandwidth problems and put the performance bottleneck back on the CPU.  My recollection is that it was too hard to solve the N^2 complexity for sensor detection phase though, which is what's burning up the CPU.  Happy to be correct by someone with experimental evidence that SSD is a lot faster, (or a better memory ) though.

Thanks,
John