FAF is using up a tremendous amount of power
-
@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.
-
there is a box to tick in settings if you want to be notified of pre-releases
-
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
Because this now allows people to message players who are offline and they will receive the message when they next come online which has been a desired feature.
-
@waterbottle said in FAF is using up a tremendous amount of power:
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.
I don't really have much to say to this outside of that it has generally been getting better as that has been the focus, and there was just one hiccup with the high amount of players that has been largely corrected now.
And just the truth that bugs with new features always have to be ironed out.
-
Just wanted to comment here that my client always lag if i switch to aeolus in chat. If i have aeolus closed there is no such lag. This is since we have everybody on away.
Why was this feature implemented by the way? I get that you can now send messages to people who are "offline" (if that would work stable), but who needs that? Feature might be good if faf is not a "laggy shitshow". I get that you can only test these feature if its implemented globally, but who asked for this? It just makes it way more confusing to see who is online.
Since this change i have to restart my faf client 4-5 times a day to have a functioning client that is not lagging (same with some of my friends) -
It was mainly implemented to try and be helpful to the moderators so they could message people who were not currently online. And it was all set up as a bit of an experiment to see if it would work with the number of players that we have.
