New tools for Delphi XE

The second sneak preview is out now.  It’s quite a bit more interesting than the first one.  FinalBuilder being added to the package will make it a lot easier for me to get builds set up for the TURBU project.  Right now I have to do it all by hand.  So far I haven’t missed a step and ended up releasing it, but if there’s a way to reduce the chance of that happening in the future I’d definitely appreciate it.  I just wonder if it’ll be in all editions or just the higher-level SKUs.

Then they mentioned AQTime, which looked interesting but IMO brings up more questions than it answers.  For example, “Since this is the standard edition, not all of the profilers are enabled.” (9:13)  But I don’t see any of the profilers on that list grayed out.  And again, will this be in all editions, or just the high-level ones?

Also, will it come with an extension to the Open Tools API to allow other profilers to be integrated?  AQTime has some great features, but its core feature, performance profiling, uses instrumenting that slows your app down horribly, which makes it unsuitable for a lot of uses.  I prefer Sampling Profiler, which gives a good picture of what you’re spending your time doing without instrumenting your program.  It doesn’t provide the perfect counting accuracy that instrumenting does, but most of the time you don’t actually need that anyway in order to track down performance problems.  If there was a way to integrate Sampling Profiler into Delphi, it would make a good compliment to AQTime’s other profilers.

As for CodeSite, I don’t have too much to say about that, because I don’t know enough about how it works to discuss it very well.  Logging’s definitely useful, but usually in different ways than what they were demonstrating on the video.  For example, if CodeSite can only output to that popup window, it’s worthless IMO.  But if it can write to a file, or better yet if it allows you to create and register custom outputs of some kind, that would be a big help.

The one thing I’m a bit worried about is price.  Delphi’s got three general problems, which need to be resolved independently.

  1. Missing features.  No 64-bit, no cross-platform, no data binding, no LINQ, etc.
  2. Bugs and quality issues.  Glitchy generics, *Insight, the helpfiles, etc.
  3. Price.  No explanation needed

Delphi 2011’s main point was supposed to be addressing a missing feature.  That ended up not happening, as the team members have been explaining, because they don’t have enough time to get it working at a good quality level.  That’s definitely a praiseworthy attitude, but I’m a bit worried at seeing all these expensive third-party tools being suddenly announced as part of the product.  They don’t actually do anything to solve the three main problems facing Delphi, and I’m a bit worried that they’ll end up taking the price even higher.

They’ve mentioned their commitment to quality several times, and specifically that they’ve done a lot of work to fix the generics issues.  That’s great, and if they’ve allocated some resources to getting a Error Insight and Code Completion working properly that’ll be even better.  But even so, not having the main missing feature we were expecting would be delivered is going to do a lot to reduce the perceived quality of the release, even if the objective quality has gone up quite a bit since D2010.  Quality improvements are generally expected to be part of an update, not a new release.  (The “I paid good money for this with the expectation that the promised features would actually work” argument.)

I really hope I’m interpreting this wrong, but what it looks like to me is that in order to avoid the new version being perceived as “just a bugfix release” that isn’t worth the price, Embarcadero decided to bundle a bunch of expensive tools to make it appear to be more worth the cost.  If that’s what they’re doing, there are two ways to do it, and both will hurt them.  Either the price stays about the same as it was for D2010, but they’re paying a share of it to the owners of AQTime, FinalBuilder, etc, so they lose a lot of revenue, or they pass that cost along to us, the price goes up, (without delivering the anticipated new feature,) and a lot of people end up not wanting to buy it at that price, so they lose a lot of revenue.

What I would prefer, and what I would do if it was my product, is to negotiate some sort of deal with the creators of these other products where people who buy Delphi XE can pick them up at a discount, and then sell the actual Delphi license to us at a reduced price.  That would help improve sales, or at the very least help stem the loss of sales resulting from not having cross-platform available, and no one ends up paying for add-on products they don’t need.  (And not everyone will need them.  Where I work we’ve got a bunch of developers and one build machine.  If we all got a copy of FinalBuilder… what would we do with it?)

I really hope I’m wrong about this, but this is what it looks like Embarcadero is doing.  I just wish they wouldn’t, since I don’t think it will actually be good for Delphi users, or for Delphi itself.


  1. CodeSite (note the spelling) has been around for a long long time, and is written by Raize Software (the same guys that produce Raize Components). It is a really versatile logging product with all kinds of logging destinations and transports.

    There are similar tools available for Delphi, but CodeSite has been around the longest.


  2. Lachlan Gemmell says:

    I doubt the AQTime IDE integration will work for other profilers. AQTime has integrated into the IDE for many years and looking at the preview video, it looks like AutomatedQA’s IDE integration is being used still rather than a generic one.

  3. Mason Wheeler says:

    @Jeroen: Thanks! Fixed the spelling now.

  4. Paul says:

    CodeSite is an excellent tool. We’re a few versions out of date and haven’t gotten around to updating it, but it will be a welcome addition to XE – assuming it is not restricted to Enterprise and Architect editions.

    I have to agree that with this version, they are bundling tools to bulk up the release into something meaningful. I doubt that will be reflected in a price hike though. The deal cut with the tool providers will give them a phenominal discount and yes it will hit their margin, but it is a hit they seem prepared to take until they can release XE2 with 64bit / cross compilation. Remember this will keep a proportion of the SA customers on board who would otherwise given up their SA if XE was not delivered at all. It will also pull in such companies as ours who have been waiting for 64 bit but who also have developed a need for unicode. Then there are the “2 versions and your off the upgrade path” people who “need” to upgrade or loose their “cheap” path to the current release.

    At the end of the day, they’re in business like everyone else…

  5. Ken Knopfli says:

    In the Borland days they’d often bundle tools and components. In one case even critical DB access tools. Then they discovered they were buggy, expired or in the case of the DB tool, were even incomplete, the original developer had flown, and by the next version or two, they’d drop the tool altogether.

    Over the years I have learned to wait a version or two before committing the intellectual investment in new features (eg. Generics, Actions), and to be VERY cautious with the 3rd party bundled stuff.

  6. LDS says:

    AQTime can use different “scopes” while profiling (class/procedure/line level), and can profile only given “areas”. You should use a top-down approach. First use an higher scope, and when you identified which areas needs further profiling select only those and go more in depth using a more granular scope. Of course if you start to profile a whole application at line level, yes, the instrumentation will slow down the application a lot.

  7. Greetings:
    I wanted to offer some inside insight on AQtime matters and clarify the some aspects of integration with RAD Studio XE.

    First of all, it is indeed the standard AQtime IDE integration into RAD Studio that is used. I can’t comment on integrating Sampling Profiler into RAD Studio XE.

    AQtime offers multiple performance profiling modes with varying degrees of overhead. Profiling areas enable selective profiling, where you can easily specify which specific functions/classes/files/modules you want to profile, once you’ve established the general areas of concern. The rest of the application will run uninstrumented at real speed. Thus, the real overhead of running the instrumented application can be managed very effectively.

    Finally, all AQtime Standard edition includes all profilers. More advanced features are provided only in the Pro edition, which is a paid upgrade. Please stay tuned for the Webinars following the release of RAD Studio XE, where we’ll focus on specific uses of AQtime Standard and Pro under RAD Studio XE.

    Happy profiling!

  8. Mason Wheeler says:

    Thanks for the clarification, Sergei!

  9. Ken Knopfli says:

    I hope someone will transcribe all these webinars and videos for people in other countries with less privileged internet access.