Long, Hard Day of Optimization – Not a Ton of Success
Getting it right and then getting it fast can make for a lot of work. And while no one said it would be easy, it's how hard it is to get the necessary speed, and what changes you have to make to the code in order to get it. Such has been my day. I've been spending a lot of time this week trying to get things faster, and while I've had quite a bit of success, I haven't had the level of success I was hoping for.
I was hoping that I'd find that one problem... that one bottle neck that slowed everything down. But that was not to be. I found a lot of little places to get a little speed: pooling data containers for the UDP datagram input and processing... reducing copying... and today - trying to make the processing of the UDP datagrams themselves faster.
When I start to mess with the processing, I invariably end up causing bugs either with changes to the logic, or the speed that was not a problem before, now has become a problem because I've tightened up the timing enough to make it a problem.
The problem today has been that I have done a lot of work, but it hasn't made a lot of difference in the overall scheme of things. I'm still backing up on the UDP datagram queue on the input. I'm better, but it's not enough to actually stop the overloading of the queue (at 100,000 elements). So it's not a real success, but I can say that I know what it isn't, and hopefully I'll be getting a lot closer to the real answer soon.