I made two quick changes to IP Address Locator tonight. The first fix was to the LookupService class I talked about a few nights ago to introduce an upper bounds check on the IP number before performing the lookup. This check in the code eliminates the need to check against the end_ip_number in the database because of the structure of that data. Because the start_ip_number of one block of IP addresses will never be below the end_ip_number of the preceeding block the query can only look at the start_ip_number and perform significantly better. When checking that the IP number is between the start_ip_number and end_ip_number the query typically takes between 0.85 and 1.10 seconds. When it’s only checking against the start_ip_number it takes less than 0.01 seconds. I’d call that an amazing improvement and it only took imposing one upper bounds check to make sure the value to look up didn’t cross the end of the data. This query is now taking tremendous advantage of the structure of the data in the table.
The second change I made tonight was a change in the way country name lookups were performed. I thought the country name cache was a good candidate to be implemented as a Singleton. I chose the implementation that relies on the JVM to execute static initializers when a class is initialized. Doing it this way produces an up-front performance hit but once the class is initialized that hit will never happen again. I did this to eliminate the need for synchronization on the method producing a (tiny) performance hit each time the instance is needed. I am aware that Java 5 correctly allows for a double checked locking implementation but I chose to pass on that way for now even though I am a big fan of Brian Goetz’s talks on threading and the volatile keyword in Java 5.
That’s all for now. Please download the IP Address Locator project and check it out. Feel free to post any questions or comments you have.





2 comments ↓
Hmm, I’m absolutely sure I’ve never suggested any form of double-checked locking was a good idea, even if it does “work” with volatile under the new memory model. There are, as you suggest, better choices.
Hi Brian,
I didn’t mean to suggest you said double-checked locking was a good idea, only that I enjoyed your talks where the Java 5 volatile keyword changes were discussed. The implemenation that I was thinking of would have declared the unique instance as volatile so your name came to mind.
Thanks for reading my site!
Leave a Comment