ID:92142
 
Resolved
Games using giant icons and/or pixel offsets, a new feature in build 463, could experience a somewhat significant increase in CPU usage for each player logged in using build 463. CPU usage for these new features has been improved. The amount of extra processing required still depends a great deal on the size of the biggest icon or offset, and should be relatively low for most games.
BYOND Version:463
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 3.6
Applies to:Dream Daemon
Status: Resolved (464)

This issue has been resolved.
Descriptive Problem Summary:

Well, I've noticed that since version 463, the CPU usage of Dream Daemon increased pretty much significantly. In version 462 and below, my game would make DD use 0% of my CPU with 1 idle player logged in, and it would continue to use 0% as more idle players log in.

Now, in version 463, 1 idle player would make the DD's CPU usage increase to 2-3% and it will keep hovering at 2-3% while the player is doing nothing but sitting around. Then, if I log in a second idling player, the CPU usage will raise to hover around 3-4%. A third idle player and it will hover around 4-5%. You get the picture. It would become pretty laggy with a lot of players logged in.

Numbered Steps to Reproduce Problem:

- Install version 463;
- Host a game in Dream Daemon;
- Log in to the game;
- Monitor the CPU usage;
- Log in a second player;
- Monitor the CPU again;
- Log in a third player;
- Monitor the CPU again;
- etc...

Code Snippet (if applicable) to Reproduce Problem:

none

Expected Results:

The CPU usage will stay at 0% when only idle players are logged in.

Actual Results:

The CPU usages raises with 1% for every idle player.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes, I presume.
In other user accounts? Most likely.
On other computers? Unable to test this; only have one computer.

When does the problem NOT occur?

It always does.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

462 and below.

Workarounds:

Uninstall 463 and install an earlier version.
Frankly at that low a percentage you could simply be seeing measurement error. I've never heard of DD using 0% on idle because even when the game server isn't working very hard, it's still working. You can't extrapolate and say you'll get X% usage with Y players because it doesn't really work that way. Unless you're seeing actual problems with a large number of players on your server there's no issue.

In addition, for those percentages to be meaningful we would have to know more about the makeup of your system: what sort of processor it's using, etc. Which game you're using also does matter; obviously we expect usage to vary between different games, and it might be that some games are using features that are more CPU-heavy than others. Without any of this data we don't have anything we can actually investigate. For these reasons it probably would have been best to continue this discussion on the developer forums.

I also suggest trying this without Firefox 3.6 running, if you had it up at the time, because Nadrew has noticed issues with programs co-running with Firefox 3.6 and my own experiences with that version have been disastrous.
Lummox JR wrote:
Frankly at that low a percentage you could simply be seeing measurement error. I've never heard of DD using 0% on idle because even when the game server isn't working very hard, it's still working. You can't extrapolate and say you'll get X% usage with Y players because it doesn't really work that way. Unless you're seeing actual problems with a large number of players on your server there's no issue.
In addition, for those percentages to be meaningful we would have to know more about the makeup of your system: what sort of processor it's using, etc. Which game you're using also does matter; obviously we expect usage to vary between different games, and it might be that some games are using features that are more CPU-heavy than others. Without any of this data we don't have anything we can actually investigate. For these reasons it probably would have been best to continue this discussion on the developer forums.
I also suggest trying this without Firefox 3.6 running, if you had it up at the time, because Nadrew has noticed issues with programs co-running with Firefox 3.6 and my own experiences with that version have been disastrous.

My processor is a AMD Athlon 64 x2 5200+ (2x 2700 MHz), the game is Final Fantasy Legacy. But since I am unable to reproduce this issue in any version prior to 463, I highly assume this is in fact a version 463-bound issue. Firefox wan't running during the testing. The 0 % is probably round from something like 0.3 (or anything between 0 and 1), but still, 3% of CPU usage when only one player is on and doing "nothing", is a big different from <1 %

Maybe it has something to do with the changed packet sending algorithm (or something like that) update? Or the fix for objects with large icons displaying offscreen? I mean, I don't know, it could be anything...
Which build of 463 are you running exactly? Also, how much memory does your system have?
Okay, I *think* I have a theory. For that fix to make offscreen objects with large icons display their icon, does it use some kind of client proc with a loop to check if there are objects with large icons beyond the view? I noticed the CPU only increases when players connect with dream seeker v463. Could that cause a few % CPU increase per player? Of course, I've never seen BYOND's code, so I probably don't know what I'm talking about, but I'm just trying to help
Lummox JR wrote:
Which build of 463 are you running exactly? Also, how much memory does your system have?

463.1065
2x 2 GBs DDR2 800 MHz
There's a server proc that does that check, but indeed it only does it if clients with 463+ log in. However, every Appearance (the sum total of things affecting an atom's image including overlays, but not images) is flagged as to whether it's using giant icons/offsets or not, and going through those flags is a pretty quick check if there are none. While just having giant icons/offsets in use will be enough to trigger a small check for every 463+ player when a turf or obj updates in their line of sight, that loop should be relatively low-impact at all other times, and it should be zero-impact if pixel offsets and icon sizes are within very reasonable ranges.

Being able to test this with the game in question would help. What is the hub entry for this game?
Lummox JR wrote:
Being able to test this with the game in question would help. What is the hub entry for this game?

The main server of the game is currently down due to server maintenance, but I have a private server hosted for developers of the game. If you need to connect, you may do so at byond://78.23.99.253:1515
Since this is a server performance issue, I would need to run the server myself to do any testing. I need either a downloadable game to test with or the hosting files for the game. If you like you could send me such files at LummoxJR@aol.com and I can take a look.
Lummox JR wrote:
Since this is a server performance issue, I would need to run the server myself to do any testing. I need either a downloadable game to test with or the hosting files for the game. If you like you could send me such files at LummoxJR@aol.com and I can take a look.

I'll mail you something so you can test.

Notice: the game uses very large Z levels not to have hundreds of small Z levels for each area. Maybe that could be relative to the problem and of-screen large icons. Also, the CPU increase per 463 client also occurs when no object with large icon is near.
This seems to be relatively difficult to test with just one person, but in 463.1065 I saw very low CPU usage in DD even when I was logged in; it would very often display 0% even while I was moving around. (You didn't confirm BTW whether you were using 1065 or another build.) I found a few places that performance of the new big-icon stuff can probably be improved, so I tried those in a test and found CPU usage slipped above 0% even less frequently--but I can't really verify whether those changes represent any kind of true improvement. The difference in our processors may be a factor, as mine is Intel and yours is AMD, and per core mine is faster (3.4 GHz vs 2.7); even though I only have the one core, that's all BYOND uses anyway. I'm not sure though there's any way I can grab better data on my end.
Different CPUs may certainly play a part in this, differences in performance demand may be more significant on one processor than on the other.
I did confirm my installation's build in post #5 if you look again.
I'll go and test this testing build now.