Drake Lag

I’ve just read with interest the two latest dev blogs about lag (Drake’s of Destiny part 1 & part 2). The interesting thing about this is that it confirms some of my predjuices about modern programming and programming languages.

I’ve probably not mentioned it before but I work in IT, and have done since finishing my degree about 25 years ago. In that time I’ve programmed, consulted, and managed systems. The problem explained in the dev blogs is a common one that has been around since the dawn of time. Poorly optimised algorithms.

I’m not going to blame CCP for this. I’m guessing that the majority of their coders are relatively young and have come upon the scene post Java and Moore’s Law. It’s something I see at work all the time. The drive has been away from programmer optimization and instead dumping it on the technology to overcome coding issues. The idea is that the programmer spends more time doing the useful stuff instead of trying to wring the best out of each CPU cycle (cue misty look into the past when a CPU cycle meant something and using one less instruction would save the day). This isn’t bad I suppose, in most cases you can just throw faster hardware at it, or scale it horizontally.

In real time operations this isn’t possible. You run out of faster hardware and once you scale massively horizontally you lose an increasing amout of processing time to keep each node in sync. In the end you have to go back to good old algorithm optimization. Something that we looked at in the second year of my degree all those years ago.

I’m sure that they are already on it at CCP, but if they aren’t maybe they should just do a trawl of the code for nested loops. They aren’t a bad thing but, in general, are sub-optimal performance wise.

I’ll get back to the more normal coverage later.