ID:1493985
 
Resolved
BYOND Version:501
Operating System:Linux
Web Browser:Firefox 27.0
Applies to:Dream Maker
Status: Resolved (504)

This issue has been resolved.
Descriptive Problem Summary:

We were using sprite-based text and switched to maptext for UI elements. After doing so, the CPU increased a good deal (this was the only change). We went from a steady 50% at ~40 people to 120%.

Oddly, maptext isn't anywhere near the top in the profiler. The profiler looks a lot better now that we've removed sprite-based text, but the CPU is much worse.

Numbered Steps to Reproduce Problem:

1.) Compile Eternia with maptext, host a server.
2.) Compile Eternia without maptext, host a server.
3.) Compare the differences in the CPU log. The version using maptext will be much higher, despite that being the only change to the code-base.


Expected Results:

Improved CPU performance.

Actual Results:

Worse CPU performance.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Unsure.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur? When maptext isn't being used in Eternia. Not sure if this is consistent with other games.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unsure.

It's hard to say what the deal is here without seeing the differences in the code, some kind of comparison between them. Typically, I would expect sprite-based text to be slower for many purposes, and I don't really get how maptext would cause that kind of inefficiency.

I'm curious if this is related to the big-icon code, in which case I'd also like to know if you see an improvement when running in 504.1230 with threads off.
If that's relevant, frames are not one big icon, it's pieced with overlays over HUD object.
HUD works by placing text overlays over frames and such. Major change was changing object that is used as overlay from sprite-based letter-by-letter to maptext.

Before:
(letter_widths stores width of letter in pixels for each character)
obj/hud/text
var/width = 0

New(text,font,ly)
src.layer = ly
var/pos = 1
var/image/i = new/image()
i.icon = font
i.layer = ly
while(pos<=length(text))
i.icon_state = copytext(text,pos,++pos)
i.pixel_x = width
src.width += letter_widths[i.icon_state]
src.overlays += i

After:
obj/hud/text
var/width = 0

New(text,font,ly)
src.layer = ly
width = length(text)*9
maptext_width = width
var/stylestr = "font-size:9pt;color:#eeeebb;font:'Tahoma';"
maptext = "&lt;div style=[stylestr]&gt;[text]&lt;/div&gt;"


Can't seem to find daemon.txt to turn threads off. Can you give us specific instructions to locate the file?

I'm only seeing: http://puu.sh/6SlXy.png
The cfg dir should be ~/.byond/cfg, not /root/byond/cfg. You'll see some files there, but it's unlikely daemon.txt will be among them, so just add a file called daemon.txt that contains "threads off".

I'll add that I'm a little skeptical now that the big icon code is responsible for any difference, since this is applying solely to HUD objects, nothing on the physical map. The fact that this would raise CPU usage significantly, vs. adding a crapload of overlays, is bizarre. Maptext should if anything be taking a lot more work off the server than it could possibly put on.
All right, after updating BYOND, and switching back to maptext, we've noticed a nice performance increase (less than 1 CPU per person).

Now that you've said that though, I'm a little confused as to what could be the cause. I don't think it's on our end because the only change we made was maptext, and we switched back and forth twice to make sure that there was an actual issue. Both times we noticed big CPU increases when using maptext, despite maptext not appearing high on the profiler.
Just to be clear, I want to confirm this is roughly what's happening:

501+overlays: 50 CPU / 40 users
501+maptext: 120 CPU / 40 users
504+maptext (no threads): 40 CPU / 40 users

Is that about right? A benchmark using 504+overlays would also be helpful to know.
Yeah, that's what we observed. 504+ w/ maptext is currently at 60 users with about 60 CPU.
Lummox JR resolved issue
Closing this as resolved, since various efficiency fixes in 504 have taken care of it.