FAF is using up a tremendous amount of power
-
@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, etcI 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 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, etcI 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.
-
I mean, until the latest release, or past few release I never had this issue. The client seems to get worse with each update, in terms of connectivity, UI lag etc..
It should improve and get better, not the opposite.
-
And yes I'm on the latest client 2024.1.0
-
@waterbottle 2024.1.1 is actually the latest full release.
There's also the newer 2024.1.2-alpha-1 if you want the actual latest client.
-
@sheikah said in FAF is using up a tremendous amount of power:
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.
Why do we need to know the number of away players? We don't need to know this, every since this came to client it started using up all my CPU somehow, it's ridiculous. Causes horrible in game lag
-
@mostlostnoob said in FAF is using up a tremendous amount of power:
@waterbottle 2024.1.1 is actually the latest full release.
There's also the newer 2024.1.2-alpha-1 if you want the actual latest client.
Ok then the client is failing to notify me there is yet another update. Player's don't usually check the github for new updates, they rely on being notified in the client like me.
