The Lair of the Pythia

So, having done all that work testing individual functions and come up with a complete blank as to what could be the problem, I tried running the software on a different computer. The Turbo-compiled version was still slower, but only by about 30 seconds over a half hour run, not the 30-50% difference I noticed before. That, ladies and gentlemen, is what Windows can do to you. It does so much helpful work in the background that you can never be quite sure what it is really up to.

Still, I did manage to learn quite a lot along the way. Also I now have some good evidence that the software is swapping memory to disc during runs. I wonder if there is any way to monitor that. Is there a useful utility out there that watches memory caching and tells you what your program does? I think that would be useful.

No progress on the install as yet, because it occurred to me that there is no point in getting the software to compile under the Turbo if it is going to be a lot slower. The client won’t be at all happy with me. So I’ve been spending a day or two trying to work out what the heck the problem is. It has been “interesting”.
Read the rest of this entry »

Well, urgent development job over, I can now get back to looking at the Turbos.

I do have the free versions of the Delphi compilers running on my back-up machine. While it doesn’t have enough poke for general development, I can at least compile the software on it. So I have been doing some back-to-back testing. The code for my program, developed under Delphi 7, compiles and runs just fine under the Win32 Turbo. It is also of similar size. But for some reason the code generated by the Turbo is between 30% and 50% slower. I’m mystified.

Timing code on a Windows platform is, of course, very much a hit-and-miss affair. Back in the days of single-thread operating systems you could get profilers that would tell you in detail just how fast your code was running. But under Windows you never quite know when processor time is being stolen by some other process. The only thing you can do is make lots of runs and look at averages, trying to keep what is happening on the rest machine down to a minimum. Even with all of these caveats, the Win32 Turbo code is markedly slower than that produced by Delphi 7.

I’ve been playing with compiler directives to see if something like having debug options set, or range checking, or something similar might be an issue, but none of that seems to have any substantial effect.

Has anyone else out there experienced this sort of thing, or know something about differences between BDS 2006 and Delphi 7 that might explain it? My program does a lot of floating point math. I don’t know if that helps track down the issue.

Meanwhile I’m hoping that at the weekend I can get back to trying to get the Turbo running on my main machine. I would at least like to know what is causing the odd behavior I reported here. As it is clearly machine-related, I guess I’ll have to start stripping out other software.

Update: Mystery solved (sort of). See here and here.

Well, thanks to the tech support folks I managed to get the Win32 Turbo installed on my main machine without it asking for a license key. Apparently D7’s uninstaller doesn’t clean up properly behind it. But there were still problems. I could not get the IDE to open my project file, even though a similar installation on my (smaller, less powerful) backup machine reads it without any problems. And now I have an urgent piece of development to do for a client so I have once again stripped the Turbo off my main machine and gone back to Delphi 7, which I know works.

You have no idea how depressed this makes me. I do hope it is something stupid that I did, but even so an error message would have been nice. But the IDE just briefly flashes up a blank rectangle on the screen, then it goes away as if nothing had happened.

Lots of things have been happening. I’ve had a couple of phone calls from CodeGear, from which I gather that their systems have got a little messed up and I’m not the only person getting confused, but they are at least trying to sort things out.

I also got the Fedex package, which turned out to be a CD of the Win32 Turbo. It is nice to have, but perhaps a little over the top for a product that is freely downloadable. I’ve been promised a registration key, but that hasn’t turned up yet.

I’ve also had email from CodeGear’s tech support regarding the problem installing a Turbo on a machine that used to have Delphi 7 on it. Hopefully their suggestions will work, but I have a small amount of international travel to accomplish first so I’m unlikely to have any news on that until the weekend.

What I can say at this point, however, is that I’ve had a lot more attention from CodeGear than I’ve had from any other software company I’ve had to deal with in recent years. One of these days I’ll tell you the McAfee support story.

Of course the obvious way to get around Turbo Delphi wanting a registration key is to buy one. I can order the Professional upgrade, and the Borland online shop is still listing the upgrades at the reduced $249 price. So I should order one.

Well actually I did. On Friday. But while my upgrade for the .NET version arrived within a few hours (still far too slow), the Win32 upgrade still hasn’t been delivered. I did get the order confirmation, but no email with my registration key. I checked the tracking page on the shop web site this morning and my purchase is described as “backordered”. Really? They are out of stock of something that only requires them to send me a registration key? How very strange.

Ah well, at least they haven’t charged my credit card yet.

I suspect what has happened is that various people are running round in circles at the Borland/CodeGear offices trying to find out who left the special offer prices online after they were supposed to expire and decide what to do about orders that have come in since the end of the year. In the meantime, however, the offer is still online, I just checked.

I am beginning to understand why so many people in the Delphi community are so very angry with Borland. CodeGear has a big mountain to climb if this is the sort of customer service people have been used to.

Today has been frustrating, and really shouldn’t have been. All I’ve been doing is trying to install a Turbo. It is, I’m afraid, a long story. Read the rest of this entry »

Generally I like to be working with the latest version of my compiler. This is nothing to do with wanting to be at the bleeding edge. I tend not to be an early adopter with other software, especially as feature bloat has got to the point where most of what gets added in new versions isn’t relevant to me. But with compilers if you are not up to date there is always the danger that some change in the operating environment will render your software unusable. System Utilities units are there for a reason, and we need them to be up to date.

Having said that, it can sometimes be a real pain to move to a new compiler if things have changed too much between versions. So if you do have legacy applications, how do the new Turbos stack up? I have a good test: a legacy application with over 30,000 lines of code. It is currently compiled in Delphi 7. Can it make the switch to Turbos? The .NET compiler is a complete bust. Many of the system units in the code don’t exist any more. It is going to take a lot of work to migrate the code to the .NET compiler.

Win32, on the other hand, was perfectly smooth. The project file needed updating, but Delphi did that automatically. That done, the code compiled first time, and the resulting software performed exactly to spec, at least as far as a hour or so’s testing is concerned. There may be dark corners of the software that do require some re-writing, but for basic Windows applications I’m guessing the Win32 compiler doesn’t require much conversion work.

So there’s one important answer: if you have legacy applications, you need the Win32 Turbo, not the .NET one.

Hopefully it will make my life easier, and I can now dispense with Delphi 7, but I’ll keep it around for a few more days while I do some more testing, just in case.