[0.3.2][0.5.1][Performance] Game is unplayably slow

[Dr.Eddy]

Hi,

I've been playing 0.2.10 the last time before upgrading to 0.3.2. In the old version my FPS was around 50, but could rise up to 70 and fall down to about 10 (if there were many creepers, the view was zoomed out and there were many items to render). That was quite fine and very playable. But now in 0.3.2 the game is very slow ALL THE TIME. FPS is in the range of 7.3 and 8.1 (being very steady), Game Update says 86-88% (also very steady). One CPU core is at 110% (as htop says), the other one at around 9% (considering only factorio).

This is Archlinux 32bit.

[MF-]

I was observing random scene jumps when running around, caused by the render-skipping feature.
I am not sure about the cpu load, I didn't look at it, because games usually always take 100% (some can be clamped down without an obvious performance impact, though)

[Dr.Eddy]

I tried it right now again, still the same result. I loaded my old save (which is large enough to see it happen) and it is still here.

Would anyone care to explain WTF is going on?

[kovarex]

Could you post save with the game?

[Dr.Eddy]

here it is http://www.uploadmb.com/dw.php?id=1371547103

in 0.2 series it was just fine.

[slpwnd]

So I played with your save. When I played in the debug build (much slower / not optimized) I got like 10fps-20fps and 60ups. The game was perfectly playable even though it wasn't smooth. Then I played with the regular build and got like 30fps 30ups or more (it was flipping between this and 50fps+ 60ups). Actually this is a bug because it should go to 60ups by running multiple updates per tick. This is caused by the trickiness of vsync. The game becomes rather slow with 30ups. Some people don't mind this some do (me). These numbers are happening on my 2 year old mac book pro 13.

When you say that your FPS is around 7 what is your UPS? There is a setting in other controls which allows you to set maximal number of updates per tick. The default is like 5. Did you try to play with it (i.e. set it to lower). You might get less UPS but more FPS. This is connected with what you consider when you say the game is "slow". Some people dislike when the game doesn't do 60 updates per second and are able to tolerate if the frame rate (and thus the looks) are shaky and on the other hand some people prefer to have stable smooth frame rate at a cost of not having 60 updates per second.

Actually at the moment I am working on main loop and update / render redesign which will allow to perform rendering and updates simultaneously in multiple threads. So the multiple updates per tick optimization will go. It will be back to 1 update ~ 1 frame. However using multiple threads (where available) should significantly push the boundary where the game FPS will go down.

[Dr.Eddy]

So I played with your save. When I played in the debug build (much slower / not optimized) I got like 10fps-20fps and 60ups. The game was perfectly playable even though it wasn't smooth. Then I played with the regular build and got like 30fps 30ups or more (it was flipping between this and 50fps+ 60ups). Actually this is a bug because it should go to 60ups by running multiple updates per tick. This is caused by the trickiness of vsync. The game becomes rather slow with 30ups. Some people don't mind this some do (me). These numbers are happening on my 2 year old mac book pro 13.

When you say that your FPS is around 7 what is your UPS? There is a setting in other controls which allows you to set maximal number of updates per tick. The default is like 5. Did you try to play with it (i.e. set it to lower). You might get less UPS but more FPS. This is connected with what you consider when you say the game is "slow". Some people dislike when the game doesn't do 60 updates per second and are able to tolerate if the frame rate (and thus the looks) are shaky and on the other hand some people prefer to have stable smooth frame rate at a cost of not having 60 updates per second.

Actually at the moment I am working on main loop and update / render redesign which will allow to perform rendering and updates simultaneously in multiple threads. So the multiple updates per tick optimization will go. It will be back to 1 update ~ 1 frame. However using multiple threads (where available) should significantly push the boundary where the game FPS will go down.

I'm sorry, but when it's below 30fps, I have a problem with it. 30fps is like a standard, it's the fps of a normal video. When it drops below 25fps, people start seeing lags.

I have between 6 and 8 fps, ups at about 30 (which is with the default setting of 5 updates per frame). Even if I had 10-20fps like you, I wouldn't like it. I don't see the point of your reply as the main problem still presists a nobody has responded to it at all: since 0.3 update the game lags. That's what you should look at. Making it multithreaded does not fix the cause, it may only soften the consequences.

If there's something important that made it so slow, that's fine. I can live with it if I know that it makes sense and it's needed. But I don't see the reason if all of sudden the FPS drops from 50-70 to just 7. Don't you think that that's a problem? Do you now see my point?

I could run factorio on 8-core 4GHz beast, if I wanted to. But I don't want to. I want it to be relatively small, simple and efficient game that I can enjoy when I just want to play something now, on a small netbook that I carry everywhere with me.

[kovarex]

So I played with your save. When I played in the debug build (much slower / not optimized) I got like 10fps-20fps and 60ups. The game was perfectly playable even though it wasn't smooth. Then I played with the regular build and got like 30fps 30ups or more (it was flipping between this and 50fps+ 60ups). Actually this is a bug because it should go to 60ups by running multiple updates per tick. This is caused by the trickiness of vsync. The game becomes rather slow with 30ups. Some people don't mind this some do (me). These numbers are happening on my 2 year old mac book pro 13.

When you say that your FPS is around 7 what is your UPS? There is a setting in other controls which allows you to set maximal number of updates per tick. The default is like 5. Did you try to play with it (i.e. set it to lower). You might get less UPS but more FPS. This is connected with what you consider when you say the game is "slow". Some people dislike when the game doesn't do 60 updates per second and are able to tolerate if the frame rate (and thus the looks) are shaky and on the other hand some people prefer to have stable smooth frame rate at a cost of not having 60 updates per second.

Actually at the moment I am working on main loop and update / render redesign which will allow to perform rendering and updates simultaneously in multiple threads. So the multiple updates per tick optimization will go. It will be back to 1 update ~ 1 frame. However using multiple threads (where available) should significantly push the boundary where the game FPS will go down.

I'm sorry, but when it's below 30fps, I have a problem with it. 30fps is like a standard, it's the fps of a normal video. When it drops below 25fps, people start seeing lags.

I have between 6 and 8 fps, ups at about 30 (which is with the default setting of 5 updates per frame). Even if I had 10-20fps like you, I wouldn't like it. I don't see the point of your reply as the main problem still presists a nobody has responded to it at all: since 0.3 update the game lags. That's what you should look at. Making it multithreaded does not fix the cause, it may only soften the consequences.

If there's something important that made it so slow, that's fine. I can live with it if I know that it makes sense and it's needed. But I don't see the reason if all of sudden the FPS drops from 50-70 to just 7. Don't you think that that's a problem? Do you now see my point?

I could run factorio on 8-core 4GHz beast, if I wanted to. But I don't want to. I want it to be relatively small, simple and efficient game that I can enjoy when I just want to play something now, on a small netbook that I carry everywhere with me.

Ofcourse, that it is better to optimise the core demands than just use more and more cores.
If you want to compare the effectivity of the update and have save that is 0.2.10 compatibile, it is best to compare absolute numbers of the time spent in the game update.
We did lot of optimisations that proved to make the game faster, so if your game is really slower, something is wrong.

I just downloaded the save, from the fact that u are using gz, I assume you are using linux. We had to do one thing that might affect linux performance, we disabled the --fast-math compilation flag, as the math wasn't working correctly (not following the IEEE). This might have something to do with your problems, and we might play a little with other flags that make the linux math faster.
The game was running smooth on my computer (60FPS/UPS and update around 20% (3400mc)), but I ran the test on windows, so it might be the cause.

[MF-]

I'm sorry, but when it's below 30fps, I have a problem with it. 30fps is like a standard, it's the fps of a normal video. When it drops below 25fps, people start seeing lags.

Fun fact: CZ DVB-T broadcasting runs at 25fps (+ interlacing)

I have between 6 and 8 fps, ups at about 30 (which is with the default setting of 5 updates per frame). Even if I had 10-20fps like you, I wouldn't like it. I don't see the point of your reply as the main problem still presists a nobody has responded to it at all: since 0.3 update the game lags. That's what you should look at. Making it multithreaded does not fix the cause, it may only soften the consequences.

Obviously, they have *to* finish rewriting the main loop ( very beneficial thing for everyone with weaker hardware. I hope I'll be able to lower the FPS to save power while travelling ) before looking at this "unplayable" (probably better that what I am getting btw)
It is also possible, that the problem will be accidentally resolved during the rewrite. Especially if that was some sort of obscure problem like cache-timings.

[Dr.Eddy]

Ofcourse, that it is better to optimise the core demands than just use more and more cores.
If you want to compare the effectivity of the update and have save that is 0.2.10 compatibile, it is best to compare absolute numbers of the time spent in the game update.

That save is 0.2.10 compatible, since I stopped playing the game when it got so slow.

I just downloaded the save, from the fact that u are using gz, I assume you are using linux.

You assume correctly. If you are unsure, you can also read my initial post and see that I mentioned that I run 32-bit Archlinux.

We had to do one thing that might affect linux performance, we disabled the --fast-math compilation flag, as the math wasn't working correctly (not following the IEEE). This might have something to do with your problems, and we might play a little with other flags that make the linux math faster.
The game was running smooth on my computer (60FPS/UPS and update around 20% (3400mc)), but I ran the test on windows, so it might be the cause.

There are many things that can influence this. And I don't think just turning off -ffast-math would be so dramatic. I don't know what kind of hardware do you have, but I'm runnning it on Atom N270. Yes, that's the old slow Atom at 1,66GHz with hyperthreading.

Also, I have no idea how's your engine written (I heard only about C++ boost). But if it's some 3rd party library that sucks on Linux, well, that's bad (mmkay). It's just that it's simply weird, to say the least, the before it ran so fine and now it hogs CPU and still runs slow. Something sinister has to be happening...

[Dr.Eddy]

Fun fact: CZ DVB-T broadcasting runs at 25fps (+ interlacing)

Yes. So?

Obviously, they have finish rewriting the main loop ( very beneficial thing for everyone with weaker hardware. I hope I'll be able to lower the FPS to save power while travelling ) before looking at this "unplayable" (probably better that what I am getting btw)
It is also possible, that the problem will be accidentally resolved during the rewrite. Especially if that was some sort of obscure problem like cache-timings.

So you're saying that the "very beneficial thing" has caused my netbook to hog CPU at 100% at 6-8FPS? In what universe is that beneficial?

[MF-]

I was just checking that you are not watching TV, because it doesn't meet your framerate standard and limit you cannot tolerate.

This "very beneficial thing" is not in 0.5.1.
Are you a time traveller, VIP, or just someone who doesn't read properly? (note: I wouldn't say it like this if you didn't provoke with even more aggressive posts)

[Dr.Eddy]

I was just checking that you are not watching TV, because it doesn't meet your framerate standard and limit you cannot tolerate.

I said below 25fps people start seeing lags. TV runs at 25fps + interlacing which kinda makes it into 50. I didn't say I can't tolerate fps below 30, I just implied I'm starting to have problems when below.

This "very beneficial thing" is not in 0.5.1.
Are you a time traveller, VIP, or just someone who doesn't read properly? (note: I wouldn't say it like this if you didn't provoke with even more aggressive posts)

The initial bug post was aimed at 0.2 series -> 0.3 series update. So I thought you were talking about that, since you wrote "they have finish rewriting", which can be just read ad "they have finished rewriting" just as "they have to finish rewriting". And I'm not aware of any aggressive posts against you.

[MF-]

The initial bug post was aimed at 0.2 series -> 0.3 series update. So I thought you were talking about that, since you wrote "they have finish rewriting", which can be just read ad "they have finished rewriting" just as "they have to finish rewriting". And I'm not aware of any aggressive posts against you.

OOps. That explains it. I am sorry about that unfortunate omission.

[kovarex]

We will do some profiling under linux on bluecubes computer, and we might find out what is wrong.

[Dr.Eddy]

We will do some profiling under linux on bluecubes computer, and we might find out what is wrong.

Great, thanks!

[Dr.Eddy]

For anyone who might be interested in this thread, the developers and I tried profiling the problem on my computer. Nothing specific came up so the conclusion is my computer is too slow to run such a big map.

The good news is improvements and optimizations should come in 0.6 series. We'll see how that turns out.

Anyway, big thanks to the developers for troubleshooting this!

[cube]

... so I'm moving this to pending, and if something changes, please bump this thread again.