Comments on: Porting SmartInspect to Tiburon

By: Nick Hodges

Nick Hodges — Sat, 09 Aug 2008 16:51:12 +0000

Jolyon -

Are you claims based on any benchmarks that you’ve done?

Wait I know the answer! No, they aren’t!!!!

Nick

By: Dave Nottage

Dave Nottage — Sat, 26 Jul 2008 01:00:24 +0000

“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.

By: snorkel

snorkel — Wed, 23 Jul 2008 20:24:49 +0000

“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?

By: Dennis Gurock

Dennis Gurock — Tue, 22 Jul 2008 13:50:18 +0000

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).

By: Jolyon Smith

Jolyon Smith — Mon, 21 Jul 2008 20:47:51 +0000

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.

By: Dennis Gurock

Dennis Gurock — Mon, 21 Jul 2008 18:32:10 +0000

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).

By: Keld R. Hansen

Keld R. Hansen — Mon, 21 Jul 2008 17:08:23 +0000

Will v3.0 still be compatible with D2007?