Why I Don't Like Microsoft

Sun, 23 Jul 2006 16:41:19 GMT

There is nothing in this entry that people haven'd before. I just needed a place to speak my mind for a second.

Recently I switched from Mozilla Thunderbird to Outlook 2003. The reason for this drastic change was that I have a HP iPaq that works great with Outlook. I can sync calendars, emails, contacts, everything; I know, a silly reason to switch. Then I remembered why I was using Thunderbird in the first place, the following (very important) file extentions are automatically blocked by Outlook and unless you're running an Exchange server there is nothing you can do about it!

url, asp, chm, js, ins, isp, its, cer - A url address, ASP pages, compiled html fiels, javascript files, IIS settings, and Internet Certificates - Well, so much for Microsoft providing ASP.NET developers with an easy to use tools

csh, ksh - Unix C shell and Korn shell scripts - I didn't even know these ran natively under windows!

mad, maf, mag, mam, maq, mar, mas, mat, mau, mav, maw, mda, mdb, mde, mdt, mdw, mdz - Everything MS Access! - This is just ridiculous - how can any company that purchases Microsoft Office but can't yet afford enterprise Exchange server work like this!

The thing that really gets me though is that there is no way around any of this. Microsoft took it upon themselves to forcably dictate what you can and can not do.

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

Why I Don't Like Microsoft

Java performance analysis - a real life example