I don’t know how roblox does their things or whatever but man i have to ask how bloated does the entire chat system have to be for this to be an issue? I’m sorry but you guys don’t get to force us to use your magic tech while having it barely perform. I don’t care if the excuse is that “well this only happens when you send a message and its not like you send it every frame!”. If my i7 14700k takes 6-8 milliseconds to “compute” a text message then how long would an i3 2100 take? How long would a mobile chip take?
Still having this issue after an entire year, I’m becoming confused as to what could be causing this lag. It clearly shows that the chat is taking a lot of computation time, and it’s not only for sending messages but also receiving messages.
Realistically all the computation power for filtering is done on the server, and the client does the rendering, only receives a message, creates a text and shows it. This is not really expensive at all, maybe the list used for the chat causes lag? Perhaps creating the text causes lag? Perhaps it’s in the code. Just ultimately very strange behavior.
The issue was gone for a while for me, but it has just recently came back, at the start of the month.
Still having this issue on our place where we have all the default chat stuff disabled and just use a custom system with TextChatService as the backend. Lots of GetFastFlag and FindFirstChild calls for some reason.
I am still suffering from huge ExperienceChatMain lag spikes leading to huge FPS drops (I got a huge drop from around 60fps to 30fps twice in a 5 seconds period)
I expect Roblox to take this issue with highest priority considering its severity, it’s timespan and the removal of the Legacy Chat System. It can’t stay as an issue forever along with all other performance issues especially the ones related to CoreScripts…
Seems like it’s a trend for it to happen in roleplay games, which are ones focused mostly towards chat (since that’s the entire medium for roleplay). It also seems to happen over time, as a gradual performance degradation the longer a client is in the server, and is fixed by rejoining.
I looked at the microprofile a bit further and it would seem like it’s still doing a lot of UI operations even with bubble chat and the chat input bar/UI disabled. Looking at DataModelPatch is a bit annoying, but possibly some incorrect cleanup of old messages plus React memos/hooks being funky is my only guess.
Folks, is it really that hard to disable the code for bubble chat and the chat window if both UI elements are disabled? Like this would immediately fix our problem in our game, and other games can easily switch to TextChatService-powered custom UIs.
This is, once again, a crucial thing to pay attention to. Roblox is going to forcibly tank the performance of every single game on Roblox with no way to avoid it.
I represent Heroes Battlegrounds. We refuse to move over to the new chat system and will continue to refuse to do so until Roblox either:
fixes the performance issues with the default UI completely disabled, or
(ideal) fixes the performance of the default UI and brings it to the same level that Lua chat had.
This lack of urgency in improving the most vital part of a social platform (the social element itself) is disappointing.
I, wholeheartedly, agree that this should be taken way more seriously. It does not seem - at least to me - as an inherently hard thing to fix. I hope that before the force, we get some performance equal to or better than LegacyChatService, because to be real, this is genuinely not right. TextChatService was not ready to be the default and only option for in-game chat on this platform, and we need to see improvement before it can be so.
Furthermore, many of the CoreScripts in general do not run that well. It would be amazing if Roblox were able to fix these problems as well, since ExperienceChatMain is not the only contributing factor to this problem.
You’re absolutely right, the most dominant CoreScripts with performance issues are ExperienceChatMain and the React scheduler that appears with the tag of SchedulerHostConfig.default. I’ve noticed that whenever I get huge lag spikes on experiences it mostly have to do with either of these two CoreScripts. There are also Corescripts like PlayerListManager, CameraModule, Topbar and CharacterNameHandler spiking and taking more resources than expected sometimes, but they’re usually less severe and spike less often.
Eitherways, Roblox should fix all of the performance issues related to the CoreScripts. It’s not logical for CoreScripts to be the main cause for the lag spikes in experiences and use way more resources than actual developer scripts. CoreScript related performance issues didn’t exist before and they should be fixed for once and all, and not be ignored and neglected like they’re currently now.
Nothing have changed still, and now we’re being forced to implement parental control, an on April 30th, we’ll be forced to use TextChatService.
Literally upon any interaction with TextChatService there’s a 1-7ms spike that appears in the microprofiler, even though there were “performance improvements” and there is “active work on it”.
Please stop with the negligence. This is starting to become troublesome. As a person who often strives for playable experience with low-spec hardware, this is stupidly annoying when something lags your game and thats completely out of your control (in that case, TextChatService)
I hope they could at least delay it until they properly utilize React, I still have no idea how they managed to screw the optimization up so much in this way.
Probably doesn’t help that they seem to try and fetch FFlags everywhere, even in the same function, without caching its result, causing delays.
For example, everytime someone sends a chat message, it checks if the “ChatTranslationUIEnabled” is true… Every single time. And no, I don’t mean they check a variable, I mean they run a function that does GetFastFlag and returns the value. I am suspecting it does that multiple times across many more modules as it passes the signal to them.
Or how about fetching the “EnableBillboardUpdateFrequency” on Heartbeat? Does that not just sound painful for the Lua engine?
Every individual call to GetFastFlag might only take 0.1ms on average, but overtime this adds up, especially in a game with lots of players using the text chat, with many bubbles potentially being able to be displayed at once, not to mention it’s running FindFirstChild as well to find the adornee instance for bubbles that have a Model as their adornee… which would be all player’s characters, wouldn’t it?
The system might have changed ever since I’ve been sent the snippets of code, and they aren’t really the source code either, so my assumptions might be wrong(!), but it just shows the code wasn’t exactly made with optimization in mind.
I don’t claim to be an expert on Lua, but surely if this many people are complaining about performance, this approach might just be wrong in its execution.
I have my doubts that they would delay the removal of it, at least for the performance issues. I just hope that they would fix the performance issues and all other bugs before the timeline, that’s the bare minimum, because later they should support missing features that were in the Legacy Chat System but currently aren’t in TextChatService. Knowing Roblox, they will most likely not do any of this, so I won’t keep my expectations high. But I hope I get proved wrong.
Regarding React, almost all of their CoreScripts that depend on it suffer from performance issues, I am not sure if this is just the nature of React or Roblox is doing a terrible job at using it properly but that’s how it is. It might be a combination of both. Honestly, I don’t get on why do they even need to use React, Lua chat (Legacy Chat System) is completely fine without it. What’s missing in Luau that they are forced to use React to compensate for? Literally nothing. Either they use it well or they don’t, which is a better choice in my opinion.
Wow! I am pretty sure it wasn’t there the first time the release notes for version 660 were out, they definitely put it there afterwards.
This is one good step in the right direction, now we just need performance improvements for when the default UI is actually being used which is true for most of the games that use TextChatService.
I also noticed a lot of waste here, especially when flags were living for a long while. 100 flag checks can sometimes add up to 1ms per frame (This is hypothetical, I didnt see any evidence of 100 flags being called per frame)!
I merged a change a few weeks ago that should have been released this week that cleans up a lot of these calls to FFlags.
That’s great, but I am still wondering on why is that with every improvement that is being released there’s almost no difference that’s being made on real-world performance. I have just tested a few Roblox games that use TextChatService and I am still getting the same spikes with the same severity as before.
I am curious in what’s the main reason for these spikes and performance issues. All I know is that the spikes are worse and happen more often the larger a game server is and the more people are using the chat.
