3 ms·

Isn't it in this case just an implementation detail without any meaningful consequences (apart from interop)? - I'm trying to find a way to benefit from it. I w

• zamalek 10y ago
  This is no implementation detail and has nothing to do with overall memory use. It has to do with how much memory is copied (an operation that consumes time) per invocation. IL is the wrong level to look at this. In the by-value case: a stack frame of 192 bytes is allocated (+ space for other locals). The values of the matrices are copied into it from the parent stack frame (128 bytes). The method does its work and then calls "new Matrix". This occupies the final 64 bytes. Immediately this value is copied out of the method to the parent stack frame. In the by-ref case: a stack frame of 0 bytes is copied (+ space for other locals). The pointers to the two matrices are passed in, as well as a pointer to the memory for the result. The method does its work and then calls "new Matrix". The result of the .ctor is stored directly in the calling stack frame. You might consider that this is nit-picking, but consider that this has to happen 60 times per second. Calculating an MVP matrix for 1000 objects 60 times per second, results in 32MB of memory copied around per second. That assumes you are doing no additional math (which is definitely not the case). The performance benefit is substantial enough that even XNA had these overloads (which is where I think the workaround originated)[1]. [1]: https://msdn.microsoft.com/en-us/library/bb194950.aspx https://msdn.microsoft.com/en-us/library/bb194950.aspx
• bad_user 10y ago
  A return means copying that value on the stack and depending on its size, it can be expensive. In this case we're talking about a matrix, so that's not just one 32 or 64 bytes pointer.