* 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. Sam
