Descriptive Problem Summary: When there's too much text in a text output, if you go into any tab (on a stat window) which uses Stat(), the game lags a lot.
Numbered Steps to Reproduce Problem: Put a lot of text in a text output, then go into a window that uses Stat().
Expected Results: No lag
Actual Results: Lag
Does the problem occur:
Every time? Or how often? When there's too much text.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.
When does the problem NOT occur? When you don't look at a stat window. For example, in a verb window, it does not lag.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Yes.
Workarounds: None.
ID:2386145
 Jul 21 2018, 5:03 pm
|
|||||||||||||
| |||||||||||||
Lag as in FPS. FPS drops. Try making a simple project with a stat panel with lots of stuff in it, that updates. Then do a lot of output with world << and then you'll notice the FPS drop. It becomes severe and can crash the game at a point.
| |
I need a test case here. When the details are vague on a report, I can often throw something together only to find I haven't done whatever critical step was responsible for the issue appearing.
| |
https://cdn.discordapp.com/attachments/454688000761266187/ 470429681145872404/lag_test_case.zip
Here's a test case with Stat() and a output, switch to the stat tab and you'll notice the huge FPS drop. | |
I don't think this is a bug. You're running at an unrealistic 100 FPS and constant output is going to cause a slowdown, and frequent updating of the statpanel can potentially slow things down as well. All I'm seeing really is that this project is setting up a worst-case scenario for performance.
| |
There's also another instance where this happens too, it's in the SS13 tgstation codebase (which runs at 20 fps), when you look in the MC statpanel (as a administrator), it lags the game a lot
| |
Isolating a "lag" issue in /tg is not likely to pan out, just because of the complexity of the codebase and the inherent time it takes even to start up.
Your test case is simple enough like I need, but it doesn't really show any serious issues. For one thing it isn't designed to actually make anything that falls under the umbrella term "lag" readily visible; when it's sending output and also doing stat updates, it's not really clear how much performance degradation is there. That is, there are no visual cues to indicate it. | |
Log, text, sound, and statpanel output all appear to be major cpu hogs for the server. I have always questioned whether it is reasonable, but lacking a better view into the internals, it is hard to say.
| |
I wonder if the meat of it isn't simply the use of FText(), the internal concept that does string embedding. There's basically string churn going on.
The string tree doesn't autobalance like some other trees do, but if it gets too far out of whack it will redo itself so in general it shouldn't be too horrible. (It used to be a lot worse, because deletions only did some very simple work on the branches.) But I wonder if the bigger isn't isn't simply all the allocation/deallocation for text. | |
I'm going to need a test case to look into this. "Lag" is such a subjective term.