If you are into Delphi, you have probably already seen all the blog postings about Tiburon (the next Delphi version) from the CodeGear Embarcadero staff on DelphiFeeds.com. Besides working on SmartInspect 3.0 (more about this in a few days), we have also worked on porting SmartInspect to Tiburon in the recent weeks.
As you might already know, SmartInspect already fully supports Unicode and porting SmartInspect to Tiburon was quite easy and took only a few days of work overall. The SmartInspect Delphi library is now using UnicodeString as the main string type instead of WideString. Porting the library to UnicodeString had a positive impact on the performance of our logging library as the new UnicodeString is reference counted (and WideString is not). The performance gain is about 10-15%, but we do not have final numbers yet.
We are happy to see that Delphi will finally be 100% Unicodified soon, too, as this makes it really easy to build applications for an international audience. We fully expect to be releasing support for Tiburon and UnicodeString with SmartInspect just a few days after the new Delphi version goes gold.
7 Comments
Will v3.0 still be compatible with D2007?
Yes, we will still fully support Delphi 6-2007 with SmartInspect 3.0 (and we will probably do this for many years to come). In fact, nothing has changed for those versions in regard to strings, as SmartInspect will fall back to WideString as the string type for Delphi versions below Tiburon (just as we use WideString in SmartInspect 2.x).
The REAL performance impact is going to be an overall slow down and an increase in memory footprint for the VAST majority of applications that don’t need and don’t want Unicode but which will have no choice in the matter (unless the authors go through their code “ANSIfying” it).
So what’s the performance “gain” for an ANSI application having it’s world Unicoded around it? I suspect that that “gain” will have a negative vector.
But I suspect we won’t hear any chosen partners telling us about that.
Of course, your application needed Unicode - it was using it already in the form of WideString, so for you there WAS a benefit - no argument for me there.
But by definition, the majority of existing Delphi applications are NOT using Unicode, and a very large proportion of those don’t need it and likely never will (and being forced to use it creates problems for those applications that otherwise would not exist).
In the face of that, the unilateral implementation adopted in Tiburon is patently ridiculous.
Unicode support in Delphi is absolutely overdue, WAY overdue, but a way should have been found for it’s use to be adopted by choice and by design.
Too late now of course.
In more ways than one.
Thanks for your thorough comment Jolyon. Of course, using UTF16/UCS2 as the new native Delphi string format will have an impact on the RAM usage compared to the old ANSI string.
However, you have to keep in mind that the entire Windows API is Unicode based. And whenever you call a Windows API with an ANSI parameter (e.g., all the *A methods in Windows.pas), Windows will convert the ANSI strings to Unicode internally, which isn’t great for performance either.
> But I suspect we won’t hear any chosen partners telling us about that.
This is a bit unfair. Just because we are partners of CodeGear doesn’t mean that we don’t have our own opinions (and are willing to publish them here).
“The REAL performance impact is going to be an overall slow down and an increase in memory footprint for the VAST majority of applications that don’t need and don’t want Unicode but which will”
I don’t see how it could be that much slower if at all because currently everything gets converted to unicode at the API level anyway, if anything wouldn’t it be a tad bit faster as that internal conversion wont be needed?
“I don’t see how it could be that much slower if at all because currently everything gets converted to unicode at the API level anyway, if anything wouldn’t it be a tad bit faster as that internal conversion wont be needed?”
There might be conversions needed for code other than API calls, though. I doubt there’ll be enough to be of any significance, however.
Having said all that, unilateral adoption is inevitable anyway; MS has said so. If you don’t want Unicode, you’ll need to choose to develop for an OS that *doesn’t* support it.
Jolyon -
Are you claims based on any benchmarks that you’ve done?
Wait I know the answer! No, they aren’t!!!!
Nick