toddw123 / RotMG_Clientless

Compatible with version X16.0.0
MIT License
11 stars 4 forks source link

CPU Usage #21

Closed Zeroeh closed 7 years ago

Zeroeh commented 7 years ago

http://image.prntscr.com/image/37fe38f3141b40c4b343d074f81020fe.png

Getting even 99% on load and when there are lots of shootack packets...

I'm thinking it's probably just the way packets are being handled but I'll do some performance analysis later.

This is with 20 clients btw.

toddw123 commented 7 years ago

Wow I'm getting 1-2% usage with 4 accounts. How many accounts do you have running? I've noticed the usages spikes at the start due to like 30 update packets that each client gets, but other then that the usages almost never surpassed 2.9mb/2% for me.

On Feb 21, 2017 4:32 PM, "Zeroeh" notifications@github.com wrote:

http://image.prntscr.com/image/37fe38f3141b40c4b343d074f81020fe.png

Getting even 99% on load and when there are lots of shootack packets...

I'm thinking it's probably just the way packets are being handled but I'll do some performance analysis later.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/toddw123/RotMG_Clientless/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AFEa2VKT78Vqhja2CSx-fy7xnXBgEt3_ks5re3QJgaJpZM4MIAgS .

toddw123 commented 7 years ago

Oh I didn't see you say it was with 20 clients. That's quite a bit to have running so I can understand the usage at that point. Is the 99% at the start (the initial update packets)? Guess I'll give it a try with 20 clients lol

toddw123 commented 7 years ago

Heres my computer running 19 accounts: http://imgur.com/yy2hymy

The usage spiked to 60% initially when the update packets were coming in, but then it dropped down to <10% the rest of the time. A few random jumps to 12-15%, but it was staying pretty consistent at around 6-8%.

Did you run it through visual studios debugger or did you just run the exe from the debug folder? I just ran the exe from the debug folder because running it through visual studios will add more cpu usage.

I also cant really say my computer is too great, its an average laptop about a year old at this point. But really i think the main thing to look at is if you were to open 19-20 game clients and attempt to do anything....how much cpu do you think that would take for you? lol so id say that both of our usages is actually pretty decent for how many connections/packets/etc are going on.

Zeroeh commented 7 years ago

That's pretty impressive usage for your hardware. I'm using an x4 860k to run these and it's strange how I would get more cpu, considering you're even having the debug output to the console which can result in a lot of extra usage. (I am running it from the debug folder, I'm half wondering if using the release feature would strip some of the symbols out and make it faster. With normal flash clients I can max out at ~10 if I set them all to 30 fps. Perhaps it may be something as low as a cpu difference (if you're using intel)

toddw123 commented 7 years ago

My laptop is an intel core i7 and it has an actual nvidia graphics card in it (not super crazy or anything). Its about a year old and it was just the average model of gaming/working laptops. I saw laptops that were 4 times as much and laptops that were about 1/2 as much, but this one i wouldnt consider it that amazing as far as spec go. I do find it interesting that my memory is at 6.9mb but yours is only at 5.5mb, yet mine is using a fraction of the cpu usage that yours is.

And as far as real game clients go, ive never tried to open more then 3-4 of them, i havent capped the fps but if i run myClient normally (which should be 60fps and high graphics settings) just the 1 client sitting on the title screen hangs out around 30% cpu. So 1 client at 30% compared to 19 clients at <10%, im pretty happy with those numbers haha.

i also would think that compiling the program for release would probably do like you said, should make it use less cpu and whatnot. I havent tried compiling it in release mode yet though, maybe ill give that a try to see if theres any noticeable difference.

edit: lol! tried it in release mode. Wow, huge drop in cpu. Same 19 accounts running: http://imgur.com/109MBSP The initial spike in cpu didnt even pass 10%. Holy crap.

Zeroeh commented 7 years ago

Nice, looks like I was right in that release config would strip some of that debug stuff that the compiler likes to stick into the executable.

When I run multiple clients it seems that just blocking some packets, the ones that require you to know projectile position, or anything with lots of math would lower cpu usage.

I think what's happening is that all the clients are collecting shootack data while I believe 1 client should be able to collect and share with the rest.

toddw123 commented 7 years ago

I think what's happening is that all the clients are collecting shootack data while I believe 1 client should be able to collect and share with the rest.

That might work if you have all the clients in the same screen/server. But i have all the clients running on different servers, so doing that wouldnt actually work. There also isnt any math in there right now that actually tracks projectiles/objects/ect, the only time it sends a shootack right now is if there is an enemyshoot packet or a servershoot packet where the creator of the servershoot is the client (which unless you programmed it to shoot its ability, wont happen). As far as i can tell, there shouldnt be anything in the packet handler that is slowing down anything. And since the client doesnt track any onscreen data right now, there really shouldnt be any major memory usage. Once every client is storing the onscreen data, then you are right it will probably cause a big increase in memory, but as it is right now this isnt the case.

edit: and just to really clear up what all is being replied to by each client, the only outbound packets that each client sends right now are UpdateAck (when it gets an update packet), GotoAck (when it gets a goto packet), AoeAck (when it gets an aoe packet), and ShootAck (when it gets an enemyshoot or servershoot packet). And the move packet, which it sends on each newtick. Right now, all these outbound packets are on a pretty simple system of "i got this packet just now, it requires me to send back this packet". Theres no math or calculations involved in sending these packets, except for move but its not an intensive calculation in the slightest. If you look over the recvThread you can see how simple it is as the moment, nothing in there would be memory intensive. No data is being collected in mass numbers or anything like that.

Zeroeh commented 7 years ago

I ran a CPU analysis and got some interesting results. http://image.prntscr.com/image/7fb1f33250ad4c909b9008f3be63a4a4.png Digging further it looks like a lot of object data is being processed. http://image.prntscr.com/image/3fcc62ab547e404eac851230ca84be28.png

Could be because I had 40 bots running this time and they were each gathering update info from them. Will run a memory analysis in a bit, looks like there might be a leak or two.

toddw123 commented 7 years ago

Yeah those are the update packets that get sent when you first login i was talking about. The game has to literally send you every single person/item/etc that is around when you login. Depending on how populated the server you just logged into is, it can be 50+ packets and each one of those packets can be massive. The update packet parses though, but that data isnt being stored right now. And getting rid of those wouldnt be smart in my opinion.

From everything ive seen sofar, the cpu usage is absolutely fine. Especially since the user isnt required to run more then 1 account unless they want too.

Zeroeh commented 7 years ago

Yeah, overall it isn't too bad and if I need to run more clients I can always just use my raspberry pi :P