FAF is using up a tremendous amount of power

Since the recent update, or at least very recently, the client is requiring vast amounts of power and CPU for some unknown reason. As a result it's causing the game and the UI to lag very bad.

What's going on?

I've always found that the FAF client feels very sluggish and heavy for what it needs to do. We could use someone with the necessary knowhow to remake the thing from scratch.

The energy for the quantum gateways has to come from somewhere...

And as always: make sure you're on the latest version. If that doesn't help, try a prerelease. Lastly without logs, we can't tell what is going on.

I know there were some issues related to infinite reconnecting to irc. Not sure if that is still the case though.

No, don't remake it from scratch. The functionality the client provides is way too complex to just reimplement the whole thing.
In the past we could gain considerable performance improvements by focusing on specific parts that used up most of the resources.

And some of the sluggishness comes from the client having to wait for answers from the api or server, which is out of control of the client anyway

With the change to the always on chat (players showing as away rather than disconnected), there were some inefficiencies with how the library was tracking player away status that could cause high usage for the first few minutes after joining aeolus.

This has been resolved in the latest 2024.1.0 release so the client shouldn't use so much resources for so long just to figure out who is away.

@indexlibrorum said in FAF is using up a tremendous amount of power:

I've always found that the FAF client feels very sluggish and heavy for what it needs to do. We could use someone with the necessary knowhow to remake the thing from scratch.

More generally remaking it from scratch likely wouldn't solve any of the issues and it would be a lot of work with how many features the client has.

And on the note of the client feeling heavy I have basically been spending the last year focusing on reworking nearly the entire client backend and how the frontend works in order to drive down both the memory usage and CPU usage as well as eliminate a significant number of small memory leaks. As well as ensure the client is more aggressive about giving ram back to the os. (Although this did get interrupted a bit by needing to deal with the DDOS)

From my own measurements ram usage has been decreased by about 50% and CPU usage has drastically dropped outside of the recent reverse due to the chat changes.

Further more unfortunately I have seen that the actual usage can vary quite a bit depending on ones CPU architecture, and unfortunately I only have one architecture I can develop and debug on, so some things are just impossible to resolve but this is going to be true regardless of the UI technology you choose.

So in summary efficiency work on the client continues to go on and has been the focus over adding any new features this last year. It is just a slow and in depth process. Small exception this past month as I got deep into upgrading and adding some chat features that will come out in the next release with the caveat that new features always bring new fascinating bugs XD.

Random thought: would it be possible/not too much work to have a simple/barebones "just-to-play" client and a more feature-rich one (i.e. the current one)?

Unfortunately no, because most of the complexity is in getting the client just-to-play. Getting to this state requires the following:

• Custom server communication protocol using websockets
• Downloading, installing, and updating the game patch files
• Full OAuth client implementation
• Additional authentication measures to connect to games
• Ability to download and install arbitrary maps and mods
• Spin up and communicate with the ice adapter
• Launch and monitor game state

All of that would be required just for a bare bones command line tool to just host and join custom games.

I often wish that the requirements on the client were lighter so that it would be more feasible for someone else to spin one up and the players could have some choice, but it is just a lot of work. Not to mention maintaining it as we change all the infrastructure as well.

Someone made an alternative client, but I forgot the name. Good chance that it is now broken anyway with all the recent changes we had to make in our infrastructure

It was Eternal and they have a forum thread about it https://forum.faforever.com/topic/4724/ethereal-faf-client-2-0

It is nice but I am not sure how much they have kept up development on it.

@sheikah You have my infinite thanks for the work that you do

I speak from the perspective of someone who can't code to save his life, so perhaps I don't appropriately appreciate the amount of stuff the client has to do. It looks like what it does is relatively simple: display a list of available games, update that every few seconds, and have an IRC client. The other functions such as the maps and mods browser are also things that I would expect not to be resource intensive: they are mostly displaying things, rather than actively processing things, right?

From your comment I understand that this might be an ill-informed perspective, though.

Yeah it can be deceptive at times.

But the reason why is because just for that list of games you have to get and fetch all the map images and details when they get updated because players like to see that.

Similar thing for the details about players in the game lists and chat, so that when someone updates an avatar you see that reflected in your UI.

If everything was just displayed as raw strings it wouldn't be that bad.

But users these days expect more XD

Just imagine, to display the current map in a lobby, the client has to
Query the lobby as to what map it's using
Check on the hard drive if a preview image for that map exists
If not, query the server to see if it's a vault map
If it is, download the thumbnail
If it isn't, then it might spend ages searching anyway
And then it has to do this for every single lobby
And then it has to refresh often enough to not make users mad
And then it has to also display who's in the lobby, where they're from, IRC chat, the vault, coop, etc

I have no doubts the client isn't perfect (despite Sheikah's excellent contributions) but I'm also not surprised it needs a lot of resources

@captainklutz

@captainklutz said in FAF is using up a tremendous amount of power:

Just imagine, to display the current map in a lobby, the client has to
Query the lobby as to what map it's using
Check on the hard drive if a preview image for that map exists
If not, query the server to see if it's a vault map
If it is, download the thumbnail
If it isn't, then it might spend ages searching anyway
And then it has to do this for every single lobby
And then it has to refresh often enough to not make users mad
And then it has to also display who's in the lobby, where they're from, IRC chat, the vault, coop, etc

I have no doubts the client isn't perfect (despite Sheikah's excellent contributions) but I'm also not surprised it needs a lot of resources

Ah, but that is a good example of something that I cannot understand takes a lot of resources. The images are, what, 1kb? If even that? And with the name of the map, fetching that information cannot be resource intensive, surely? Loading a website contains significantly more information and certainly isn't difficult or resource intensive.

@Sheikah I guess my question boils down to: what part of the client takes all the CPU power, in the current version? What process is going on that holds my poor CPU cycles hostage?

Most often the CPU hog is the chat and specifically the chat user list.

In the most recent version the library we use for chat was tracking more information than we needed so I short circuited it.

Often it is the chat that has the most cpu cycles because it has the most updates as players join and leave.

You should be able to test this by disconnecting from chat and observing if the resource usage goes down

Why would that consume so much CPU time? It's maybe a few dozen state updates a second at the absolute most. Back when I maintained the Python client after rewriting the chat code I didn't see much CPU usage. All I used at the time was a Python IRC library, some Python data structures to keep track of players and IRC users, a Qt model and view implementation, and Qt itself. Despite a lot of it being Python, I don't recall it taxing the CPU much.

It is two fold. The first is that now that we have tracked away status on the chat server the number of users reported in the list went from ~1500 to >9000 so just more users to keep track.

The second is that the library we are using to interact with irc (KittehIrc) tracks users and their states using snapshots where it has an immutable user object and then whenever a change to the user is made it marks it stale and on the next fetch retrieves the new user object. And this happens for all the irc state objects. This combined with initializing all the player objects at the start of the client resulted in many state changes and objects being created.

This excessive state tracking is removed in the most recent version of the client as I wrote something that is more efficient for our usage since we don't care about all the information irc passes.

@sheikah I feel I have to reiterate that I do not have any experience in coding, so disregard this if it doesn't make sense... BUT

The first is that now that we have tracked away status on the chat server the number of users reported in the list went from ~1500 to >9000 so just more users to keep track.

Does this mean that the launcher is constantly verifying the status of each individual user? Surely it should be the other way around, where a person logging in 'announces' its state has been changed? From the perspective of my limited understanding, waiting to receive updates for users logging on and logging off sounds rather passive, and I can't see how that takes much resources.

No this is a push system so the server sends us updates.

The main CPU usage was just because when you first log in you get all the user info at once. So eventually after a while it dies down. And the newer versions removed more unnecessary tracking so this high process time is even shorter.