UDT efficiency

[Tom Hanlin]

As Adam ONeill noted in the SourceCode forum:

Also, this is not the place to ask, but why can't you pass a UDT with BYVAL, since it would speed things up a bit right?

In fact, it is almost always going to be much more efficient to pass a UDT by reference. Passing by reference means that the compiler is passing a single 32-bit pointer, which takes up little space and can be accessed very quickly. Passing a UDT by value would mean putting every byte in the UDT on the stack, padding it as necessary for alignment and dword size (the stack has special requirements here). In general, this would be much slower and would consume more memory.

With a traditional "by value" approach, this problem would also affect strings. PowerBASIC finesses the issue: instead of "byval" causing the entire string to be passed on the stack, it makes a temporary copy of the original string, and passes the temporary copy by reference.

I agree that it would be nice to have a genuine BYVAL option for passing UDTs-- mostly for compatibility with outside products, in the odd event that they passed UDTs by value.

-------------
Tom Hanlin
PowerBASIC Staff

[jcfuller]

agree that it would be nice to have a genuine BYVAL option for passing UDTs-- mostly for compatibility with outside products, in the
odd event that they passed UDTs by value.

Tom,
Not so odd. A number of api calls want a point udt byval.
I use a union in these cases.

James


------------------

[Cecil Williams]

Tom,

Have I missed something about what JC Fuller said above. My understanding of passing structures in C is using the address of operator "&" in front of the variable, this is in effect the same as passing a pointer that has the address of the structure and that is passed "by value" to the function. Just what you got through saying I believe.

Could you please clarify this?

Cecil

------------------

[Peter Stephensen]

Tom --

Just to be sure: what is fastest: f(s as string) or f(byval s as string)?

Regards
Peter


------------------

[Michael Mattias]

I've seen this, "which is faster, BVAL or BYREF?" question often.

The answer is: it depends. If the dataname is referred to more than once in the called procedure, BYVAL is faster. If referred to once, it's a wash. And the use of REGISTER variables I think turns off all the rules).

Of course, if you want to update the datname, BYVAL is useless.

With strings, I'm not sure that applies, but it seems it would, as passing a string is passing an OLE handle rather than the address of an OLE handle.

Frankly, unless you are on "optimizing" mode, I don't think it's worth thinking about the difference.

MCM

[Tom Hanlin]

JC: Yeah, the Windows APIs are always doing something unfortunate. However, the POINT type (or POINTAPI as Win32API.inc has it) can be conveniently represented as a QUAD, so it's not a major issue.

Cecil: Passing a UDT by reference is the same as passing a pointer to the UDT by value, yes. However, it is possible in C to pass a UDT by value, although it's not a common practice. The Windows APIs do pass the values of the POINT type by value in a number of instances. There are so many rare and curious beasts to be found in the jungle of Microsoft's SDKs.

Peter: Passing a string BYVAL means that a copy of the string needs to be made. This would be true even if PB pushed the string data onto the stack rather than making a temporary copy to pass byref. So, passing a string BYVAL is always going to be slower than passing it BYREF. On the other hand, as Michael notes, it isn't going to make any noticeable difference in most cases. As long as you're not passing 2Mb strings repeatedly in the inner loop of that function...

------------------
Tom Hanlin
PowerBASIC Staff

[Cecil Williams]

Tom,

Great explanation!!!!

Cheers,
Cecil

------------------

[Cecil Williams]

Tom,

It just struct me that the C++ CLASS object would just be the thing Adam is hinting about.

Sure would be nice for PB to have the CLASS structure added in the next version. Gee, hope Stephane doesn't read this one!!!

Cheers,
Cecil

------------------