OSNews

Benchmarks are very tricky things. Details can make all the difference.

Thus, I would not necessarily take the student's results at face value, without investigating further. I don't know D, so I can only throw out some thoughts that come to mind from reading the blog post. Perhaps someone else could look through Github and check out the code?

First, doesn't D have a generational garbage collector? (http://dlang.org/garbage.html doesn't say -- but it does approve of generational collectors.) The student says that he's collecting on every frame. Is he doing an ephemeral collection, or a full collection? 7 milliseconds seems kind of long for an ephemeral collection ...

Second, what if he collected every 5 frames instead? He's collecting on every frame because he's paranoid about making the 60 Hz cadence. But he made it -- so he now has some room to experiment. He gets 7 ms of overhead by collecting on every frame, but what if he gets 8 ms of overhead by collecting every N frames? This would still make the cadence -- but save a lot of battery! (Suppose he frequently creates objects that are referenced in the next frame -- but that almost always die within N frames. Then he's incurring a lot of unnecessary overhead by forcing the collection on every frame.)

Third, he just dove right in and completely removed GC. But did he really have to do that? Profiling-driven optimization tends to be amenable to the Pareto principle. 10% of the work might get you 90% of the benefit. Sometimes, tweaking 1 line of code gives you 90% of the benefit. The poor performance of the garbage collector might've been caused by just a few classes.

Edited 2012-09-07 06:08 UTC