RSS feed for InstantSpot site EdomGroup Blog

Mozilla Thunderbird Update Not Completing

Fri, 15 Jun 2007 14:35:00 GMT

Recently, I had an issue with Mozilla Thunderbird not being able to update. It would download the update, but not be able to install it saying it could not update some files. This would pretty much render Thunderbird useless because the update would try to run every time I started it and I would never be able to get into it.

The Fix - Stop Logitech QuickCam Software

Apparently, having a Logitech Webcam running can cause the updates to fail which is a freak compatibility issue I guess, but stopping QuickCam10.exe in my task manager sure enough allowed the update to run.

Just thought I would share this in case anyone else is Googling this issue without success.

Mike.

EdomGroup Now On InstantSpot

Sat, 31 Mar 2007 02:42:41 GMT

Well, we finally caved in to the peer pressure we have received from so many of the developers we admire. We, like many of them have decided to move our blog here to InstantSpot.

Actually, we weren't really pressured. We do however know Aaron Lynch and Dave Shuck, the creators of InstantSpot, and know how passionate they are about making InstantSpot a great community and resource. Just talking to Aaron and Dave, it's hard not to be interested in what they've done here and where they wish to take it.

So far, we are really happy with the decision. I have gotten all of our post moved over, but haven't figured out how we'll do the comments yet, so we apologize, but you won't get the value from our older posts that commenters have added.

InstantSpot Hello's

We'd like to give a couple shoutouts to some of our friends who have been on InstantSpot a while, or plan on joining up soon, and encourage anyone reading this blog to check them out. We are very lucky to know plenty of intelligent, kind, and hilarious people.

Kari - Sup? We are "keen" to learn much great baby knowledge from you despite our current lack of babies to try it on. It's probably a good thing, we haven't quite figured out how they work yet anyway. They seem to suffer from a lack of good documentation. Thanks for working to fix that. :-)

Chau - My girlfriend and my inspiration for almost everything I do, especially how hard I work haha. She's considering joining us on InstantSpot and I hope she does so more people can realize just how cool she is.

Conrad Davis - One of the coolest developers around, Conrad is a man I've been honored to know and work with in the past.

Dave Shuck - Manager of the CFUG, InstantSpot creator, and someone who manages to inspire you know matter how little you may get to talk to him.

Aaron Lynch - Man of random hilarity, InstantSpot creator, and an excellent ColdFusionista / CFUG participant. A good man, indeed.

Anyway, thanks for everyone's time and interest and we hope to hear from more of you as we blog a bit more often with a lot more interesting items.

Mike Kelp
EdomGroup

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.