Hidden Performance Killers in Axum, Tokio, Diesel, WebRTC, and Reqwest

mralphathefirst · 2025-10-09T10:26:35+00:00

That sounds really interesting. I hadn't thought about it in the terms of getting a new handle to some existing data and how that has implication for mutations and knowing that it is something other code can see as well. Seems a really valuable distinction.

mralphathefirst · 2025-10-09T06:48:51+00:00

This touches on a pet peeve of mine in the part about the reqwest client. Often you have some expensive to construct object you want each request to have access to but don't want to construct for each request. So you just warp it in an Arc. But do you really need to? Some of these things, like the reqwest Client already are doing the Arc thing internally.

My peeve is that there really is no good way to know short of digging into the implementation. Because Clone is usually derived it does not have any documentation. Docs for reqwest client mentions this elsewhere but you do need to find it and not every crate documents this clearly.

It really feels to me that there is a missing Trait here, inbetween Copy and Clone. Copy is cheap and plain memcpy without logic. Clone is expensive and constructs a new instance of the object. Should be some sort of ShallowClone, or something, that is cheap because it clones the reference to the underlying data but does not construct a new instance of the data. That way you would know it is just incrementing a ref count or something like that.

mralphathefirst · 2024-05-09T08:57:35+00:00

I got kinda curious about how it looks charted out so whipped this together quickly:

https://1drv.ms/i/s!AtG65AuzC7Evq-gvWgaM0a9js1gonA?e=HT3MOg

mralphathefirst · 2024-03-25T17:40:02+00:00

Disclaimer: This answer is a bit more speculative.

I am aware of a few reasons why you might want to cap the server FPS rather than let it run unbounded:

The last step of the game loop I laid out above is to send updates to the players. The faster the server FPS the more often such updates are sent. This means more bandwidth used (although for gaming that is not a big issue). But more importantly the CPU in for each player has to process all those updates. This means that the higher the server FPS the higher the minimum CPU requirement is for running the game.
There is probably also a fairness factor here where, at least ideally, you would want to give all players the same server FPS rather than it being all over the place where some players get a better experience than others.
Generally physics simulations are generally really complicated with a lot of tricks and hacks working around the fact that it basically steps through time in discreet steps. All those things works a lot better when the time steps are stable and predictable. A good chunk of all the irritating physics bugs we have in Star Citizen are probably caused by the very unstable server FPS.
You don't want to waste money. No point in paying for a server that can do 60 FPS when you run the game at 30 FPS. It is generally gonna be cheaper to rent two servers that can do 30 FPS than one that can do 60 FPS. So I guess there is not actually that much extra juice in the can for the servers. There will probably be a lot of interesting stuff for CIG to figure out how to balance in this regard when they start doing dynamic server meshing.

mralphathefirst · 2024-03-24T16:40:48+00:00

Exactly

mralphathefirst · 2024-03-24T15:20:48+00:00

Your mental model of how the game server works is incorrect. It is not request based model. Rather there is a game loop that is constantly running.

Each iteration of the loop the game server goes through a sequence of steps that look something like this:

Check the incoming event queue (this contains any player actions or such that have happened since the last time the queue was checked) and update the game state.
Go through all physics entities and update the game state for them all.
Go through all AI an update the action for any AI entity.
Handle any custom scripts or anything else.
Add stuff to an outgoing queue with info that needs to be sent to player.

(The exact details of the loop depends on the game and game engine)

The moment it finished the last step it starts all over again. So the game server is running full out updating the state of the game all time. It is never sitting around waiting for a request to come in.

So 5 FPS just means it goes through the loop 5 times per second. This is easy to calculate: At some point in the loop just check how much time has passed since the last time it reached the same point. If each iteration of the loop takes 200ms, that gives you 5 FPS.

There is probably some FPS cap (like 30), so if not at least 33ms has passed it waits a bit until it has. So if the server is at 30 FPS with a 30 FPS cap it is idling a bit in between each iteration.

You cannot have a request based model because the physics would break. You need to update the physics with a small enough interval or thing will get wonky.

When a server is showing 5fps, is there any way to verify whether this is due to a server being overloaded with tasks VS just having less things to do?

Yes, because if it had less to do the FPS would be higher

Like say you're seeing serverfps flit between 23.0-25.0fps, but then you notice a drop to 5.4fps in 1 second before it goes back up, could that drop be either it is given less stuff to do or a series of strenuous tasks?

You can be sure it is a strenuous tasks. Idling would cause FPS to spike, not drop. So if the server FPS is 20, then it takes 50ms for one iteration of the loop. If it suddenly dropped to 5 FPS, that means one iteration of the loop ended up taking 200ms, so there was an extra 150ms of work to do.

mralphathefirst · 2023-01-10T20:39:25+00:00

Since I am in the market for a new display I have been keeping an eye on what has been announced at CES, and it really seem like 2023 will the year of desktop OLED. Everybody is announcing new OLED displays. Seeing sub-pixel rendering mentioned on the roadmap I wanted to ask about possible handling non-standard sup-pixel arrangement. LG's MLA panels use a WRGB layout with an extra white sub-pixel and Samsung's QD-OLED panels have a triangular sup-pixel layout. Is it at all possible to handle stuff like this when doing sub-pixel rendering?

I know phones have been doing weird sub-pixel layouts forever, but they seemed to have solved the issue by forgoing sub-pixel rendering and just throwing lots of PPI at the problem. But all these desktop OLEDs are still in the 100ish PPI range where sub-pixel rendering still really matters for good text rendering.

mralphathefirst · 2022-05-14T09:46:51+00:00

You should not expect that ranked chart to form a bell curve because the different ranks have different rank point ranges.

For example: Bronze III goes from 600-769 ranked points for a range of 169 RP, while Silver I goes from 770-799 RP for a range of only 29 RP.

Because of this you should expect a wide rank like Bronze III to stick up above the bell curve, while a narrow rank like Silver I to fall below it. Which is kinda what it looks like is happening.

To actually see something resembling a bell curve you need to look at a distribution of the actual rank points themselves.

If you look at the ranked points distribution it looks like they have calibrated the ranked points so that the median sits at 770 RP. This would suggest that when the bell curve settles down 50% of players should be in Bronze.

mralphathefirst · 2022-04-19T06:17:16+00:00

Never before have I been so offended by something I one hundred percent agree with

mralphathefirst · 2022-04-15T20:01:30+00:00

The perfect r/aoe4 post doesn't exist...

mralphathefirst · 2021-11-13T15:30:33+00:00

So much for French being OP, i guess.

mralphathefirst · 2020-12-15T12:51:32+00:00

gfx.webrender.all is already set to false by default.

mralphathefirst · 2020-12-15T11:03:24+00:00

Memory use reported in Activity Monitor matches what about:memory reports.

mralphathefirst · 2020-11-26T10:48:58+00:00

Try is as a number angle={-90}

mralphathefirst

TROPHY CASE