Computing time problems

In my last few games I’ve been experiencing major performance/ computing time issues. I wanted to ask, is this my problem or has anyone else realized?
It’s weird, since I really shouldn’t have that much computation time as I always calculate (pretty much) the same things every game and I barely ever get any damage due to computation time.
28 damage from timeout???
13 damage from timeout? and my opponent, @paprikadobi, had 9 aswell
normal game for comparison (I sometimes have 1 or 2 damage, especially against demuxes, that’s normal)

So I’m worried now, has anyone else had this lately?

If you compare the first game to this one:
(I chose it, since it has the same number of turns)
Wefw has a way lower computation time aswell.

I see some >6,000 ms times in the first game…

Having the same issues when a lot of simulations are turned on… i’ve been adding breaks on if time.time() > startTime - 4.8: break to slow for loops.

I had this issue in season 1. Don’t remember the thread about it, but I do remember the solution I used. If I recall correctly, something funky is going on with the time and your algo thinks it’s only using a normal amount of time. So, in addition to using time.time() - start_time to measure out how long the turn takes, I also factored in a boolean check for game_state.my_time >= 6000, which tells you your time from the previous turn directly from the game engine. If that’s true I significantly reduce my number of simulations like I would with the time.time() - start_time check.

1 Like

Exactly my point, my algo really shouldn’t do that…
I always have all simulations “turned on” and the computation time shouldn’t change to such an extent, idk.

Hmm yes, I’ll try that, thanks.

For further comparison, compare these two :joy:

We did make some pretty significant improvements to the way the server tracks how long the algos have been running. Ill investigate a bit and see there are improvements to be made if you send me your algo

Thank alot!

Wait the code for my algo?
Don’t you have acces to that anyways?

We do, but it saves me a bit of trouble. If you don’t have it immediately on hand/available I can go pull it up.

No, sure I’ll pm you

The originina thread where this was discussed a bit more (primarily for C++) is here.

When did you first start noticing this slowdown? What percentage of games were affected? Are these ‘slow games’ still happening just as frequently?

For now, you may want to consider adding a hard stop that submits your turn or skips steps if you are low/out of time

To anyone else: Have you noticed similar issues?

All insights are beneficial.

I noticed it about 7 hours ago (when this thread was made) and it was only 3 games. In my most recent game, against the new free oracle version, it did not happen.
Yeah, for now I‘ll add a hard stop system I guess.

It looks like the same issue I posted about in the link Isaac provided, which dates back to mid December. I haven’t been following the issue since, mostly because my solution seemed to take care of the problem and the C++ port of the simulator might be keeping me under the time limit even with a slow down. But back then it seemed to occur a fair amount. 1 in 10 matches? 1 in 20?

I don’t think I got it to reproduce on the Playground to see how long my algo thought it was taking, but I did find it odd that it seemed to run simulations that should’ve been closed off under high computation times. That led me to rely on game_state.my_time over a time.time() check, just in case the very fabric of time was bugged.

I swear this is not just me though…

After reducing my simulations:

and even @Ryan_Draves is affected

I appear to have neglected my computation timeout on the more intensive escort attacks… You can see the times plummet the turn after I take damage (confirming game_state.my_time works), but only scramblers keep the reduced state…