Comments on: TValue is very slow!

By: Chris

Chris — Thu, 18 Mar 2010 20:26:33 +0000

Joylon – ‘rather than creating something entirely new from scratch’

That’s a rather ironic thing to say given the performance issue in question arises from TValue ultimately piggy-backing on something old, namely the long-standing internal routine that gets invoked whenever one record with managed fields is assigned to another. Moreover, there remains the basic point that, contra what the help says, TValue *isn’t* a ‘lightweight version of Variant’ at all, but something different with a different purpose.

Now of course, maybe the Variant type *should* be extended to better reflect its name rather than its OLE Automation-supporting origins – for myself, I’ve always found it odd that it supports native Delphi strings yet not native Delphi objects, and as a result, barely gives you much more than the strict OLE Automation subset that is OleVariant, D6+’s custom variant support notwithstanding. Nonetheless, that’s a distinct issue to the one at hand.

By: Jolyon Smith

Jolyon Smith — Wed, 17 Mar 2010 20:42:55 +0000

Then extend Variant or use Variant internally, rather than come up with a.n.other entirely new “like a variant but not Variant” implementation. At the very least take the bit’s of Variant that are performant (yuck word) and add the twiddly bits that are needed, rather than creating something entirely new from scratch. But as I say, I suspect that this approach wasn’t “sexy” enough.

By: Chris

Chris — Wed, 17 Mar 2010 13:30:41 +0000

Joylon – what’s with the snark? I take it you haven’t actually tried to put something as basic as (say) an enum value or an object reference into a variant? Obviously, you could hack this, but the code required would presumably mean replicating a lot of TValue if the actual type (and not just the ordinal value) is to be roundtrippable.

By: Jolyon Smith

Jolyon Smith — Tue, 16 Mar 2010 21:13:00 +0000

I’m curious … if TValue is more specialised and Variant is more generalised, then it seems to me that Variant’s could have been used everywhere that a TValue is used, so why re-invent an inferior wheel ?

As a type intended for the basis of a scripting engine, it seems to me that Variant would also be a natural choice for any other form of dynamic invocation, reflection based or not (most, if not all, “scripting engine’s” involve some form of dynamic invocation, no?).

I suspect collective noses were turned up at Variants because they weren’t “Generic” enough (note deliberate capitalisation and air-quotes).

By: François

François — Tue, 16 Mar 2010 18:54:04 +0000

@Mason and commentators,
Very interesting reading. Thanks!

By: Barry Kelly

Barry Kelly — Tue, 16 Mar 2010 13:06:50 +0000

And FWIW, your timings are likely to be processor sensitive. I ran it on my high-end desktop:

Variants: 473
TValues: 21853

By this test, over 40x slower

By: Barry Kelly

Barry Kelly — Tue, 16 Mar 2010 13:01:44 +0000

TValue isn’t optimized for speed, and I wouldn’t describe it as “a lightweight Variant”. It’s explicitly designed to not be like Variant – Variants can change type depending on context, while TValue doesn’t. TValue is designed to model the Delphi type system dynamically so that values can be transported with high fidelity to and from dynamic invocation. Variant was designed to model Excel spreadsheet cells, and extended to be the basic type of a scripting engine – naturally it has had far more focus on performance.

But yes, things can be improved with TValue performance wise, but be aware that any gains in practice will be limited owing to the fact that the overhead of reflection-based invocation will still add up. The dynamic invocation logic can itself be optimized by precomputing more things and reducing the number of copies, but again it’s still not going to be competitive with native invocations.

By: Mason Wheeler

Mason Wheeler — Tue, 16 Mar 2010 10:28:27 +0000

Robert: I tried those and got:

Variants: 1551
TValues: 1977

Much better!

Ken: *grin* I guess I’m still learning.

By: Ken Knopfli

Ken Knopfli — Tue, 16 Mar 2010 06:36:36 +0000

I learn a lot from your blog.

You post your posit, then dozens of pundits chime in to show where you are going wrong.

By: Robert Love

Robert Love — Tue, 16 Mar 2010 05:17:07 +0000

Here is a type safe version of the two methods that results in similar performance, with TValue being slightly faster. I am sure it could be optimized more if conversions need to occur.

class operator TValue.Implicit(Value: Integer): TValue;
begin
result.FData.FTypeInfo := System.TypeInfo(Integer);
result.FData.FAsSLong := Value;
result.FData.FHeapData := IInterface(Nop_Instance);
end;

function TValue.AsInteger: Integer;
begin
if (FData.FTypeInfo = System.TypeInfo(Integer)) and Assigned(FData.FHeapData) then
begin
result := FData.FAsSLong;
end
else
Result := AsType;
end;