Weird performance slowdown

[NihilRex (OP)]

Not sure if really a bug or a performance note.

Running Aurora6. 3 on my primary battlestation, with massive processors and ram.  Win7x64

Lately, every turn generation takes about 60-90secs, no NPRs found yet, began while I was still locked in Sol, in fact Ive only opened one new system so far.

Watching Resource Monitor, Aurora is only managing a max of 10% CPU and a tiny bit of disk access.   68 B/sec during the turn generation.   1day, 5day, 30day all take about the same time, but 5secs go quickly. . .

Not sure what if anything I can do.   Attempting a Compact Database causes a lock that requires a Taskmanager shutdown of the program.

[Erik L]

Did you start the game with a NPR (the default is 1), and the spoilers on?  They will explore and possibly find more NPRs and fight.

[Jorgen_CAB]

Aurora is using older Visual Basic code and can only use one CPU and the RAM you have is hardly relevant unless you have an older machine. This would explain the low CPU load.

If you don't have an SSD disk this might also be a minor issue since the game basically saves everything to the database on the disk all the time.

You can have a huge civilian fleet or your NPRs might have, these will make sure slowdowns do happen. Don't subsidise the civilians too much or you might get too much lag from a that fleet. As far as I understand the code is not optimized in regards to civilians scraping older models. In the new 6.4 version Steve has mentioned that some of this will be fixed and that civilians will be able to build even larger ships as well to mitigate this problem. Although it would not solve your problem...

Those are the thing I could think of aside from what was mentioned above.

[NihilRex (OP)]

Unfortunately, it isnt that kind of slowdown, where the intervals get slower.  shorter.

It is more like the turn generation routine \ database access just randomly locks for a time, then unfreezes and instantly finishes the turn. 

There are 4 civvy ships on my race, not sure about the NPRs, obviously. 

I thought about the disk access thing, but 68 B/sec average during the wait for next increment seems rather low to be a I\\O issue. 

If I knew more about how to track\log this Id offer the info. 

[Jorgen_CAB]

It could still ba a civilian issue where one or more NPR have a huge civilian fleet. Civilians are calculated every one day as the minimum cycle if memory serves me right.
You could check and see how many systems have been found in the game in the Ctrl-F9 menu. Now you can at least see how many systems have been found by all the NPR in the game.

I was talking about slowdown between turns not about shorter sub-pulses being incurred because of combat. How much do the physical CPU work that aurora works on?

You could try to turn of hyper-threading of that is on, that will often increase the speed for most CPU intensive games and Aurora in particular quite allot. Hyper-threading is not good for games in general. You could also try and give Aurora.exe a higher execution priority although I doubt that will do much unless there are other things going on with your computer at the same time.

[NihilRex (OP)]

Im not sure how to turn off hyperthreading.   I locked Aurora. exe to one processor, and again to one particular core, with no result.

Looks like 17 entries in the Ctrl-F9 table.   The highest number is 2191, which seems to be a Unique ID, not a count, since the max is set to 1000 systems. . .   (Ive never seen that screen before)

Ive backed this DB up and reverted to an older DB and am doing setup, will advise whether it recurs.

[Jorgen_CAB]

If Hyper-Threading is turned on you will see twice as many CPU in Task-manager as you have physical cores and you turn it of in your computer BIOS.

If you have something like Drop-Box I could take a look at your game and see if I get the same result and perhaps look at the DB and you NPRs and see if I can find out what is your problem?

[Sematary]

Im not sure how to turn off hyperthreading.   I locked Aurora. exe to one processor, and again to one particular core, with no result.

Looks like 17 entries in the Ctrl-F9 table.   The highest number is 2191, which seems to be a Unique ID, not a count, since the max is set to 1000 systems. . .   (Ive never seen that screen before)

Ive backed this DB up and reverted to an older DB and am doing setup, will advise whether it recurs.

I know this is a bit old but I thought I'd put out there that if you have real stars on the max system doesn't work.