Hey guys
Hey guys,
I am wondering whether exists any performance penalty (or any kind of penalty) in changing this code:
if IsManagedType(T) then
CopyArray(Pointer(@Destination[DestinationIndex]), Pointer(@Source[SourceIndex]), TypeInfo(T), Count) else
Move(Pointer(@Source[SourceIndex])^, Pointer(@Destination[DestinationIndex])^, Count * SizeOf(T));
to this code:
if IsManagedType(T) then
CopyArray(@Destination[DestinationIndex], @Source[SourceIndex], TypeInfo(T), Count)
else
Move(Source[SourceIndex], Destination[DestinationIndex], Count * SizeOf(T));
I didn't understand the need of an untyped pointer casting.
Thanks a lot :D
I am wondering whether exists any performance penalty (or any kind of penalty) in changing this code:
if IsManagedType(T) then
CopyArray(Pointer(@Destination[DestinationIndex]), Pointer(@Source[SourceIndex]), TypeInfo(T), Count) else
Move(Pointer(@Source[SourceIndex])^, Pointer(@Destination[DestinationIndex])^, Count * SizeOf(T));
to this code:
if IsManagedType(T) then
CopyArray(@Destination[DestinationIndex], @Source[SourceIndex], TypeInfo(T), Count)
else
Move(Source[SourceIndex], Destination[DestinationIndex], Count * SizeOf(T));
I didn't understand the need of an untyped pointer casting.
Thanks a lot :D
Look at the disassembly for both, verify against simple types (integers, doubles, records holding these), reference types (classes, pointers to records) and managed types (interfaces, strings, etc).
ReplyDeleteJeroen Wiert Pluimers Many thanks :D
ReplyDeleteCopyArray() alreay has the ability to check the RTTI. If there is no nested managed types, it will use a plain Move(). So your code does not have any benefit - only the risk to break something, by being more complex.
ReplyDeleteA. Bouchez CopyArray is not able to handle ordinal types (tested on XE8.1) when I copy arrays of Int32 I get stuck on invalid pointer operation :( Thanks for the explanation :D
ReplyDeleteHorácio Filho You are right. There is no type information for ordinal types, so move() is required.
ReplyDeleteAbout two ways of coding, using pointer() does not make any difference in the generated asm, since move() and copyarray() already expect a plain pointer parameter, so it is already done by the compiler.
The only exception is if Source[] or Destination[] are RawByteString, but I expect this is not the case, right?
A. Bouchez You are amazing :D Thanks a lot. Why RawByteString is an exception? I don't know the reason, using RawByteString do I need to back to the pointer() way? This code only run on mobile compilers where RawByteString is not supported, but ARC will come to desktop platforms too and I want to support it as well :D
ReplyDeleteHorácio Filho In practice, the compiler sometimes does magic when compiling expressions like PChar(aString) or PAnsiChar(aRawByteString) or @aString[1] or @aRawByteString[1], whereas pointer(aString) and pointer(aRawByteString) do not. It calls LStrFromPChar or UniqueString, depending on the context. But it is not your use case, so your code would just compile fine, and the compiler would eliminate the unused copyarray/move branch when applying the method to a given T type. Don't worry.
ReplyDeleteA. Bouchez Thanks a lot :D You helped me a lot :D
ReplyDelete