On Nov 13, 2007, at 10:12 AM, Sam Liddicott wrote:
* Michael Van Canneyt wrote, On 13/11/07 08:47:
On Tue, 13 Nov 2007, Sam Liddicott wrote:
Michael Van Canneyt wrote:
On Tue, 13 Nov 2007, Graeme Geldenhuys wrote:
* They tend to be slow compared no native types. In
Delphi 6 they were very slow. How does it compare
in FPC 2.2.0?
They are slower than native types, there is no way around this.
Almost each and every operation involving variants has some
implicit calls
to variant support routines.
If the variant type is the correct type, no casts are done and the
whole thing
is very quick.
Exactly: IF.
this means
a) Check if. This by itself involves a call to a helper routine.
It can be a simple compare. The delphi variant code that I
disassembled was inline (hence "twice as big", doesn't involve a
call but a simple compare).
The simple compare to determine the variant type is nothing compared
to the overheads that will exist between the two systems
communicating using the variants.
b) convert if not the same
With native types it's just a straight copy.
With variants it is usually a straight copy, and in cases where it
usually isn't you were going to have to convert by hand anyway.
You should see that it is more than double the size.
If that doesn't convince someone that variants are SLOW, then I
don't know
what will. Use -al for compiler options.
Twice as big doesn't mean slow at all.
Just have a look at the code before saying that :-)
I have disassembled the delphi variant code, ls -l doesn't give an
indication of execution time.
Most of the extra code covers different branches based on the
variant type,
most of the extra code is NEVER used but there "in case" because,
as you say,
pascal is a type safe language.
It must be checked, each time over and over again. Just look at the
code.
The check is cheap. The conversion doesn't need to happen over and
over again unless you want it to.
People who really want to can use the variant to aid a one-off
conversion to a native statically typed variable, and this is STILL
neater and simpler and less error prone than managing a manual type
check and conversion and dealing with any error.
I would much rather have pascal manage the variant and conversions
for me than
I have to manage it and get it wrong.
The point is that you don't need to do conversions when using typed
variables.
This is not true; take most situations where variants are being used
and you see they are being used to manage conversions. Type-ing of
variables does not avoid the need for conversion. (Variants are
typed in both senses, but I know what you mean).
Variants may or may not be a hack, but they are less of a hack than
the alternative.
If people use variants when not integrating with duck-typing systems
then they get the performance penalty they deserve.
In this conversation I'm thinking of using variants when integrating
with COM systems, etc;
Perhaps you are thinking of lazy users who make everything a variant
so they can have some kind of loosely typed compiled pascal-script.
The fault would be with the user, not the variant.
I think it is the same debate between C++ programmers et PHP
programmers. The first group like strong type checking because they
want to know exacty how their data must be. The second one don't care
of it and want lazy programming.
I do not agree with that, variant are not needed the most of the time,
you always have a pascal routine to make your convertion if needed. If
you always need a convertion, may be the type/modeling is not
appropriated. Even if we have powerful computer nowdays, it is not
necessary to add useless checks/code. We seek for performance because
you don't want to be forced to have a 3GHz to open an explorer...
Another reason would be that I observe with a lazy programming
language that programmers don't take care of their code and provide
unmaintable code.
But it is only my thought
--
Damien Gerard
[EMAIL PROTECTED]
