If you can post a self-contained example I’ll take a look, although CodeGear would probably be the most appropriate to look at any actual problems.

procedure TForm1.DBGrid1TitleClick(Column: TColumn);
{$J+}
const PreviousColumnIndex : integer = -1;
{$J-}
begin
if DBGrid1.DataSource.DataSet is TCustomADODataSet then
with TCustomADODataSet(DBGrid1.DataSource.DataSet) do
begin
try
DBGrid1.Columns[PreviousColumnIndex].title.Font.Style :=
DBGrid1.Columns[PreviousColumnIndex].title.Font.Style – [fsBold];
except
end;

Column.title.Font.Style :=
Column.title.Font.Style + [fsBold];
PreviousColumnIndex := Column.Index;

if (Pos(Column.Field.FieldName, Sort) = 1)
and (Pos(’ DESC’, Sort)= 0) then
Sort := Column.Field.FieldName + ‘ DESC’
else
Sort := Column.Field.FieldName + ‘ ASC’;
end;
end;

There may be a couple of small surprises but there’s no longer anything truly befuddling or inexplicable in there.

“But what’s really baking my noodle now is that in Delphi 2007 the two cases give different results – TANSIString is consistently 33% faster than TString! In Delphi 7 results are identical (matching the faster of the Delphi 2007 results).”

This may be just an artifact of code alignment in the library code, something which is more or less impossible to do anything about, and can drive anyone, trying to measure performance, crazy.

Thanks for the detailed and insightful comments.

No, I didn’t follow those discussions you refer to, but I am aware of the difficulty with metrics.

I think the playing field was levelled as far as possible (following the “Redux” testing at least) given that I did not set out to establish the fastest possible code producable from each compiler but rather given the same set of typical conditions (bog standard project settings etc) how did the results from each compare.

One thing I haven’t seen mentioned here is code alignment. From the FastCode experience, we know that code alignment can be the decisive factor for best performance – and we have no control over that!

Experimenting with the code, adding nop instructions here and there to align the inner loops can give a large boost, which immediately is lost as soon as *any* code is changed *anywhere* else in the project…

Then there’s also stack alignment of local variables, which also can give measurable differences for anything larger than two bytes. This can partly be controlled, by adding dummy declarations, but there isn’t any real control over this either.

AndersI

As for the results file, I was also thinking of people who don’t use Microsoft Office at all.

My feeling is that external factors should lead to variations and inconsistencies in results – i.e. in this case sometimes String might be faster than ANSIString and vice versa, or the difference may vary, but this strange discrepancy in Delphi 2007 is consistently repeatable even if I reverse the order of the tests (run ANSIString cases before String), for example.

As far as multithreading influences might go – SmokeTest runs it’s test cases on a worker thread, separate from the main thread. I am running the tests on a dual core system, but SmokeTest is implemented to detect this and in an N-core situation it sets the affinity of the main thread to CPU 1 and the worker thread to CPU 2.

It’s not perfect but it should, in theory at least, remove context switching artefacts from the results if nothing else.

CPU Cache is a good point and I have a “note to self” to investigate adding calls to flush the CPU cache (something I discovered when researching my VMT patching hack) for performance test cases.

I shall re-run the tests with these changes in place and post the results.

@Bruce – I probably should but I’m not sure that SmokeTest itself will even compile on Delphi.NET and the compiler versions are accurate enough for Win32.

I did think of saving in an older Excel format but the gradient colour scheme used in the results wasn’t portable, according to the file-save-as warning that I got anyway.

But as well as the Excel viewer, there is also the Office Compatibility pack that, aiui, will allow older Office applications to open 2007 files:

http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4aee-8f43-c6bb74cd1466&displaylang=en