Archive for June, 2007
Found this great memory stress tool — called Safari
So I was surfing around Apple’s website this afternoon and found this new Windows download called Safari. Wondering what it is I downloaded and installed it. Turns out it’s a great memory stress tool. Check out this screenie of it using nearly 300 megs on my Vista x64 system.
This is great! I was able to see how all my other apps work in low memory situations. As useful as that is, right before I was going to write this blog entry I discovered this wonderful app also renders web pages. Holy cow!! This is too much. What are those Apple guys going to think of next?
Use String.Compare — sometimes
I recently came across this blog post on using String.Compare instead of the tried and true method of converting one string to lowercase and comparing to a known lower case value. It’s important to remember that strings in .NET (as in Java) are immutable so the act of lower casing a string will always make a new string. The memory subsystem for .NET is turned for handling lots of small objects but the fewer objects you create, the fewer that have to be checked and managed by the garbage collection system.
Still I wondered what the time difference would be between the two approaches. So I setup a very simple test where I compared the string “FooBar” to a string variable that contained the value “foobar” one million times. The first test used the approach of lowercasing the first string and then doing a simple equality comparison. The average time spent for the entire loop was like .12 seconds.
The second comparison was to use String.Compare(“FooBar”, s, true) where s had the value “foobar” and true means to do a case insensitive comparison. The average time spent in the loop was .10 seconds. From this we can deduce that we should always use String.Compare right? After all it’s faster and definitely consumes less memory. Well, not always.
My next test was a common scenario where you compare a value to a series of known values. In this test, my input was the value “FooBar2″ and I compared to “foobar”, “foobar1″, and “foobar2″. With the first test, I converted it to lower case just once and then did the comparisons using a series of if/else statements. Time in the loop was .19 seconds.
The second test used String.Compare for each one of the if statements. Time in the loop was .34 seconds. So if you are doing a single string comparison, then String.Compare is your friend. If you are doing a series of comparisons, then use a switch statement or the lowercase approach if speed is your concern.
Looking a gift horse in the mouth
I’ve been following the comments to Jamie’s latest post and I have to say that most of the people who left comments are not thinking logically about this. Most (not all) are outraged that Microsoft would try to prevent Jamie from enabling his most excellent TestDriven.Net product on the Express line of products (Visual C# Express, etc).
As a consumer I would love to be able to use plugins in the Express products. I use Visual C++ Express to code on the MySQL server frequently. However, I’m smart enough to realize when I’ve been given something for free. Let me say this slowly and clearly: Microsoft is a business, not a public service. They didn’t have to make the Express products available at all. It takes a great deal of time and money to build something as complicated as these products. To my way of thinking, they made a reasonable request. Use our free products for as long as you want. If you want to use extensions, then buy our full product.
There are many companies (including us) that look for ways to differentiate between a free product and a for-pay product. I guess these people think that Microsoft shouldn’t have any for-pay products. Why doesn’t Microsoft just give away Vista and Office too! After all, I’m a consumer and I want that. That’s all that really matters, right?