Timeline for Binary Heap (list-based)
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 10, 2018 at 17:01 | comment | added | VisualMelon |
@t3chb0t don't get me started on in as it is designed... there is no technical reason a ByVal can't be readonly; in has those semantics because it has to, but means that someone else can modify the value for you if they want to (e.g. on a different thread or from a called method). Contemplating in has caused me a significant amount of misery, and as you correctly note, it would take a lot of documentation to explain in full. I'd better stop before I start hyperventilating. in is bad for my health.
|
|
| Oct 10, 2018 at 16:51 | comment | added | t3chb0t |
@VisualMelon I agree with both of you. This could degrade performance too. Unfortunatelly such things are not mentioned in the official documentation so without deep knowledge about what it's going on under the cover one can easily create a bottleneck. On the otherside, however, making the parameters readonly with in can prevent mistakes by overwriting the initial value.
|
|
| Oct 10, 2018 at 16:11 | comment | added | VisualMelon |
in makes me sad. Hardly anyone understands it. I would advise against using it unless you have a good (demonstrable) reason (i.e. you are passing around large structs and can show it provides a significant improvement). In theory, much of the benefit of in could be had through better optimisation on the part of the CLR (which in will actually get in the way of). As Pieter Witvoet says, it can easily degrade performance, and means the parameter is invariant. Reference types as in have only semantic advantages (i.e. readonly and returnable by-ref). But otherwise a good answer ;)
|
|
| Oct 10, 2018 at 15:32 | comment | added | Pieter Witvoet |
I ran some tests before I commented, and using in (or ref) was only faster when using relatively large value-types (I tested with a struct containing 4 integers). With int, long and a test class it was slower.
|
|
| Oct 10, 2018 at 15:13 | comment | added | t3chb0t | @PieterWitvoet mhmm, an interesting theory - anyone to prove it? ;-] | |
| Oct 10, 2018 at 14:35 | comment | added | Pieter Witvoet |
+1 for demonstrating something I didn't know yet (in), but it does introduce an extra level of indirection which can make things slower. And on 64-bit systems pointers are larger than (32-bit) integers, so passing an integer directly should be faster than passing its address.
|
|
| Oct 10, 2018 at 14:10 | history | edited | t3chb0t | CC BY-SA 4.0 |
added 789 characters in body
|
| Oct 10, 2018 at 13:55 | history | answered | t3chb0t | CC BY-SA 4.0 |