Monday, 19 January 2009

Some are more equal than others!

I've been trying to evaluate some scripting solutions for a Delphi application I'm working on. One of the things we do a lot of is repetitive calculations. So we wrote a small test example to try this out. It's a very contrived example, but it should give us an idea of how fast these solutions are. We basically nested two loops, and did some random mathematical functions inside the inner loop and put the results into an array of doubles. The details are not too important, but the first thing that stood out is how blindingly fast Delphi is. And by contrast how excruciatingly slow these scripting solutions can be. Some were better than others, but all were magnitudes slower than the native code. I kind of expected that, but not by such a margin. The best solution was surprisingly VBA at five times slower than native Delphi. Not sure if Microsoft still licence it though. I guess we may have to rethink how scripting will work in our application.

Now to the title. What's equal to what? Well, I was wondering how fast the same code would be if I wrote it in .NET. I chose C#, and was surprised to find it marginally faster than native Delphi code. Well, not that surprised. I expected it to be fast, maybe as fast as, but not faster than Delphi though. It wasn't by a lot, but it was impressive nonetheless. I guess the optimisation's that are now possible when using a JIT compiler are beginning to outweigh native codes inherent speed. I'm sure there are some things always suited to native code, but for most things, the fear that .NET is going to be slow is unfounded.

Just for the sake of it, I decided to rewrite it in VB.NET, expecting the same result. Wow, almost twice as slow. I wonder why. And the executable is more than twice the size of the C# equivalent. Ok, now I was really interested, so I wrote the whole thing in Delphi Prism. Syntax wise, apart from the usual begins and ends, the Delphi Prism version feels more like the C# version than the .NET version, and the performance is almost exactly the same as the C# version. The executable is 4 times the size of the C# one though. I managed to get it slightly smaller by getting rid of the icon, but it's still larger. Why? I'll investigate later with reflector.

Finally, I wanted to try and use the asynchronous features of Delphi Prism. Nothing too complicated. So I just split up the outer loop into ranges, and used Delphi Prisms async keyword.

var x := async ExecuteIt(0, 2000);
x; //Waits for the async method to execute

Since I was timing how long the whole process took, I used the waitable result of the asynchronous statement to make sure each of my chunks were ready before I stopped the clock (but I made sure they didn't wait on each other). On my dual core CPU, the resultant application ran almost twice as fast as the synchronous version. The extra method call, plus switching overhead making sure it wasn't exactly double. Pretty cool stuff, and I've only just touched the surface.

Monday, 12 January 2009

Is Google your cup of tea?

I've just read a report that says that every time you do two Google searches, it produces the same amount of carbon dioxide as boiling a kettle for a cup of tea. Wow. That's a lot of tea. Or rather a lot of carbon dioxides!

The problem is we're addicted to Google(replace the search engine of your choice here). Not addicted in a "a little bit of a therapy, and I can give it up" kind of way, but the "I just can't live without it" way.

Just today, I was trying to install CruiseControl.NET. I installed IIS, then installed Cruise Control, then tried to bring up the Web Dashboard.


Now what? Well, 2 minutes and half a cup of tea later I had my answer. It's a problem with IIS when installed after the .NET framework. Just run the following command in the framework folder (my case c:\windows\\framework\v2.0.50727)

aspnet_regiis -i

This apparently resets all the necessary registry keys. I tried this, and viola, it worked.

What did we use to do before the Internet and Google? I don't think they used to pay us enough for the job we did. I would have had to go out, to the local bookstore, and find a book about Continuous Integration, buy it, and hope it covered that particular problem. How many cups of tea would that have involved?

I say we should just give up on tea!

Sunday, 11 January 2009

Working from home

As I approach the fifth anniversary of working from home, I'm starting to think about the pros and cons of working remotely. Joel Spolsky has said many times on his blog and his podcast that he thinks developers should be in the office, and not work from home. Jeff Atwood his co-conspirator on the Stack Overflow podcast meanwhile is currently working from home on, with another two developers, who are also working from home (and I don't mean his home!). He obviously thinks it's a good idea. So do I.

I get my own room, with a closing door, something I would not have at the office. I start working in the morning completely fresh, as opposed to being worn out from the hour commute. On top of all that, I'm happier than ever, because I get to see my daughter growing up. A happy developer is a contented developer is a productive developer.

Ok, so what's the catch? Well, I'm sure not everyone is cut out for working from home. It can get lonely I guess, but I have my own social life, and it never did revolve around the geeks I worked with. (no offence, I'm a geek too, just prefer the company of non-geeks to try and keep sane!) I have a fast broadband connection, with vpn access into the network at work. So I'm just in an office with a long network cable. I checkout, I commit, I do all the usual things I would do if I was in the office. Some cite communication, or lack of it as a problem. I guess it can be, but I can discuss things over the phone (for some reason, company policy prohibits Skype), I can "look over someone's shoulder" using VNC or Webex. I regularly review code with both developers and testers. It works well.

Not to be 100% biased, I would say there are two major problems, and unless you can overcome them, they might make working from home difficult. The first is motivation. Or rather lack of it. I've been doing this for so long now, that I get up in the morning, and just 'go to work'. That happens to be down the hall from the bedroom, but it's where I work. There are times when you just can't concentrate, and there are other times when you can't stop concentrating. It's the same when you're in an office, it's just that in the office, your boss is around, so you pretend to work. At home, I know that if I'm not concentrating now, I'll be productive later. So I'll do something else. The work get's done. That's the main thing. The second problem is paradoxically, the opposite of the first one. Knowing when to stop! Separating work from home life. I confess that I have more problems with this one than the first. I have no real solution for this one, except perhaps a nagging wife!

Thursday, 8 January 2009

Delphi Prism Web Templates

I've been trying to do a few Silverlight examples with Delphi prism, and I keep getting all kinds of errors when creating the projects. I've noticed though, that it only happens if I try and create an ASP.NET test project for the Silverlight application. Then I noticed I have no ASP.NET template for Prism. Does anybody know why Delphi Prism (my copy at least) has no web templates? I think Oxygene did have them, but I can't remember for sure?

Can I get the templates from somewhere?

What is it about Garbage Collection?

I've been looking at some of the questions that people have been sending Bob Walsh to ask Nick Hodges (See my previous post) Apart from the clamour for a 64-bit compiler, by far and away the most popular question is "Why doesn't Delphi have garbage collection?" What is it about garbage collection that so excites the masses? Ok, you can create objects and forget about them. But seriously, Delphi developers, have you ever found it a major problem? I mean this isn't C++ (or God forbid C). If you're disciplined, and we're not talking military discipline here, then I don't see the problem.

I see all these comments like "With garbage collection, I can get on with solving the problem at hand rather than waste time managing memory."

How much of our time is wasted managing memory?

Tuesday, 6 January 2009

Do you want to ask Nick Hodges a question?

If anyone is interested in asking Nick Hodges a question, Bob Walsh of 47 hats fame will be interviewing him on Friday. Go here to suggest a question or two? Most of the questions so far are the usual fare (Where’s 64-bit support?), but since most of the readers of the Business of Software forum are probably not Delphi developers, it may be a interesting to see what those on the outside think. It’s also an opportunity to ask some intelligent questions that perhaps encourage a few non-Delphi users to migrate.

I know, I know. One post I’m bemoaning the state of the Delphi world, and my next I’m trying to drum up support. What can I say, Delphi is in my blood.

Thursday, 1 January 2009

Positive Delphi Post

I’ve been a bit negative towards Delphi in my last two posts, here and here. Actually they were negative towards Codegear/Emarcadero and not to Delphi. Delphi has been good to me, so here’s a positive post.

One of the major reasons people/companies say they can’t use Delphi for any new work is the uncertainty of where Delphi will be in a year. They say things like “What if Borland/Inprise (remember that?)/Codegear/Ebarcadero are not here in a year’s time?” All pretty good questions, but ones I’ve been hearing since about Delphi 4. The thing is Delphi may actually be in a better place than Microsoft technologies! No, here me out!

If I’d have started a project a year ago, and chose Delphi, I’d have used Delphi 2007. Right now I’d be upgrading to Delphi 2009, and adding Unicode goodness to my application and looking good for the future. Now, if I’d have decided to write my application in C# or VB.NET. I’d have probably gone for a Winforms application, and have used Linq to SQL to get to SQL Server. Well guess what, Winforms and Linq to SQL have been superseded. You’re supposed to use WPF and Entity Framework from now on, even if those two technologies feel decidedly beta at the moment. Who knows what they’ll have replaced them with in a year or two. There just doesn’t seem to be any plan there.

Happy New Year.