It is a well known practice. In this case, you can easily load the same configuration and replay the same queries on the Perl and Go servers, then compare. This means that you have only a single component to test. Supposing the author had selected a different configuration format, he would have had to also check that the configuration was correctly created and loaded. It also allowing the author to put a single server in production to load test once the preliminary tests give good results.
It also makes it much easier to roll back to the previous implementation. If he had created a new configuration file format, he'd have to keep the old and new config files in sync until the new implementation had proven out. Speaking from similar experience, that's no fun.
Try this: the new software reads the old config file format, so we can stagger the roll-out (install new code on some servers while keeping the old code on other servers), and expect things to keep humming along with no downtime and a simple fallback procedure if we see any problems. The new code should perform better than the old code, that's why we wrote it.
It's fast enough for now, so investing more time in making it faster would just be spinning wheels.
I haven't done detailed profiling, but the geoip lookup is pretty fast. I think more time is spent picking IPs to return (weighted from a list of sometimes thousands of IPs) and likely more time than that is in the underlying DNS library (which hopefully will get better over time without me doing anything!).
Both the Perl and the Go versions are optimized more for developer time, correctness and robustness over raw performance. I only have so much time to work on it and lots of you depend on it working, so I think those are appropriate trade-offs.
If it was a full-time job more than a hobby maybe it'd make sense to do the work in C instead of Go (but probably not).
