Data Handling

[Eric]

Speed vs. Executable Size & Production Time:

I was modifying the packet handler in one of my recent bots which removes individual packets from a buffer, puts the data in a structure and then passes it to a function to be processed when I noticed that I could just use a single CopyMemory() call to get & store the header from the packet instead of using 3 function calls (GetBYTE()  [2x] & GetWORD()), as I was doing previously.

Technically, nearly every packet can be handled this way and doing so would greatly improve speed, but it would be very time consuming to give each packet it's own structure and doing so would dramatically increase executable size.  Obviously, the change that I made wasn't much of a burden, especially since I was already passing the data as a structure, but my question is: to what extent should this be taken?

[Arta]

I tried writing a client where every message was a class once, and I got sick it very quickly. Generally, I use a struct for the header and then parsing functions for the data.

That said, defining structs for messages wouldn't increase exe size much and would improve performance a little. I'm not sure it really matters though: message parsing is *highly* unlikely to be a hotspot in your application.

[Kp]

I'm not sure it really matters though: message parsing is *highly* unlikely to be a hotspot in your application.

Well, we did reach ~20% CPU usage for a span of a minute or so one day due to message handling.  Of course, that was because somebody with a really fat pipe had turned loose a floodbot and battle.net was sending each of us over 384k/sec.

[Adron]

What would be a hotspot in a testbncs server? Message parsing?

[tA-Kane]

I would venture a guess that the best way to test a bot for bottlenecks is to run it on the slowest machine you can find and then pump it full of data with the fastest machine you can find.

Time to break out that thing that's barely worthy of the title 'computer' that's sitting in your closest which is acting as a dust collector!