An Unbiased Description Of Interfaces

Tue, 25 Jul 2006 13:43:22 GMT

For a long time I've been reading everyone wanting interfaces or not wanting interfaces in ColdFusion; make it more like Java or make it more abstract. No one has yet described what an interface means to them (since most think of or only know of Java interfaces). So, for anyone reading and for people just coming to ColdFusion or programming in general I supply this short list of what an interface is. No opinion, just the description of an interface/protocol as used in the Object Oriented Programming paradigm.

An interface is:

the list of operations understood by the object
the arguments these operations can be supplied with
the types of results the operations return
What #1 - #3 mean is that you as a developer can be handed an object that you have no idea how it works but because it adheres to an interface you know what it does. This also means that you can write an interface for something you need -say image resizing- and use that interface throughout your program. Then give your interface to some other programmer to develop and as long as they adhere to that interface it will work in your code.
the invariants preserved despite modification to the object
An invariant is a condition that does not change. The simplest example I can think of is where you have an object with two fields (variables): VariableA and VariableB then in a method that receives an argument and sets the value of VariableA the value of VariableB should not be changed after the method returns. This is important because if you call a method you have to have a clear understanding not only of what was modified but what wasn't.
any exceptional situations the client using the interface must handle
Error handling is important especially when code is being written by more than one person. Supplying the exceptional situations of a method is a good way to ensure that everyone is on the same page.

Java performance analysis - a real life example

Fri, 02 Jun 2006 03:43:25 GMT

For my thesis I'm writing a Java program that parses two text files (representing satellite images) and performs some analysis on them. The two files are 128 MB and each was taking ~33 seconds to parse. The analysis takes only a fraction of that time, then the results are written back to an output file.

Thinking this was very slow, since the files should be pretty much sequential access off the disk and the read-ahead-buffer would have cached the next block, I decided to dig a little. I rewrote the parsing algorithm in C since it's easier to manage the low-level IO. I used the file stream functions (fopen,fread,fclose) provided by stdio. When I ran the program it took ~10 seconds.

This was insane. Java does have more overhead due to its garbage collection, HotSpot optimizer, and object memory management but it should not be a magnitude of 3x slower. After a few minutes looking at the Java implementation I realized I had forgotten to instantiate a BufferedReader. I immediately jumped to the documentation and there it was, each call to the read method of the FileReader blocks until data is available. If no BufferedReader is supplied this means a context switch for each call. No wonder Java was taking so long. Adding the buffering I reran the algorithm and wow, 13 seconds. Not to bad for a “boated” language.

Figuring I had more places in my program which could be optimized I began looking. The first place I went was to one of the main methods, the one which did the analysis on each image. The logic was pretty simple, find the next pattern in the given image, see if it exists in a lookup table, if so update its statistics or create a new key and add it as a new entry. The data structure I was using for the lookup table was a simple HashMap object. When writing that section of the program I was still relatively new to the Java language and just went with what I'd used in other languages, an associative array.

I did a little analysis with some System.out.println statements and found that on average there was a 14,000 : 15 ratio between reads and writes on the lookup table. Knowing this ratio was pretty stable (I wasn't going to get anywhere near 50% writes) I decided a better data structure would be something with read time of O(n) or less, instead of O(h(k)) where h(k) was the hash function on the key. This meant an array would be best, but I didn't want the hassle of managing the size of the array as new patterns where found. Java had to have something for this. After a little searching I found java.util.concurrent.CopyOnWriteArrayList. This was exactly what I needed. After a little tweaking the new code ran in 1/3 the time.

After this I wrote some small timed programs to examine the running time of the HashMap data structure and the CopyOnWriteArrayList. What I found was as the mutations approached 25% the CopyOnWriteArrayList's performance slowed at an exponential rate. Finally, I couldn't evaluate the performance because the tests were taking too long. On the other hand, the HashMap data structure had a fairly constant performance time irrelevant on the read/write ratio.

RSS feed for InstantSpot site EdomGroup Blog

An Unbiased Description Of Interfaces

Java performance analysis - a real life example