RSS feed for InstantSpot site EdomGroup Blog

I'm A CFEclipse committer!

Mon, 30 Apr 2007 21:10:49 GMT

So, while I've been kind of a "sleeper" contributor to CFE, I have been ramping it up a bit lately and doing a little more than just keeping Mark Drew company and providing awkwardly humorous conversation. It's always wierd because you can't hear the person on the other end laughing with you...after years of messaging, I'm still self concious :-P

Anyway, more on the subject of this post, Mark Drew has decided that I'm finally worth the honor of having commit rights to the CFEclipse Subversion repository. Mainly this means two things to me:

Mark Drew doesn't think I'm gonna blow it up (or that the odds are better that I won't)
I feel like it means I have contributed some use be it in little bits to the project. I'm eager to see this contribution grow.

Anyway, whether you have been considering helping out with CFEclipse or not, I would like to reiterate how exciting it is to get to work with Mark even on the days I'm not able to do much more than discuss things with him. He has a way of making great things happen with CFE and making the entire process interesting and a lot of fun.

If you would be interested in experiencing the good and rewarding time that I've been getting, might I suggest contacting Mark to share your skills and see if there is something you'd like to do.

I'm not sure if this was an item everyone would be excited to hear about, but I'm very happy about it and I have noone nerdy to share this information with right now.

Thanks for putting up with me :-P

Mike Kelp

CFEclipse - Learning and Helping

Sat, 01 Jul 2006 01:51:16 GMT

So Eclipse 3.2 is officially out and pre-empting it was a nice new beta of CFEclipse 1.3.

Recently (end of May), I started helping out the CFEclipse project with some bug fixes and contributing to a few small improvements for the project. While I only came into the project in time to make an incredibly small contribution, I am planning to be as big a part as possible in the next release.

This brings me to my next point:

Learning

Mark Drew is, for lack of better words, a badass. I didn't realize when I initially offered to help that he has literally been the only full developer on the project for a while. The fact that he kept going says a lot about his passion for the project and his commitment to the ColdFusion community as a whole. I only hope I can contribute to CFEclipse even half as much as he has. I think it is important that we all realize this because in addition to all that Mark has done, he has put up with a lot, and kept his attitude quite well despite.

Helping

So anyway, while this blog is still new and not many will see this, I would like to remind those of you that can to contribute what you can to CFEclipse if you are using it. Get Mark something off his Amazon Wishlist or purchase some CFEclipse schwag.

Or, if you are really committed and brushed up on your Java, come help out! I can say from experience that Mark went out of his way to make me feel good about helping out and we've even gotten quite a few laughs via Google Talk.

Anyway, for whoever reads, remember how well off a particular piece of software can make you (particularly in the open source community and that IDE you got for free) as well as how the people that gave you that product deserve all of our respect and appreciation.

Thanks for subscribing to this moral outburst.

Mike.

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.