Usage of ValueTask in BaseAssertCondition

[AnnaSasDev]

After analyzing the source code, I noticed that Task is used extensively, even in execution paths that do not involve actual asynchronous operations. Since Task allocations introduce unnecessary overhead, replacing them with ValueTask in these cases would be more efficient. ValueTask avoids a lot of overhead when returning completed results synchronously, theoretically improving performance.

I've tried to compile some of these changes of Task to ValueTask in https://github.com/AnnaSasDev/TUnit/tree/valuetask but I'm unsure if this is correctly working given I don't have a deep understanding of the implications it might have on auto generated code. When I try to run all tests, a lot of them are failing (the same that are failing before the changes), so I can't very with 100% certainty that this won't affect anything.

(and yes, if this is something that is moved forward, then the docs about custom assert conditions have to be edited again 😅 )

[thomhurst]

If you create a pull request I can run the pipeline against it and tests should verify if things are actually broken or not

[AnnaSasDev]

I've made pull request #1859

[vbreuss]

After updating to TUnit v0.13.0 in my benchmarks both the memory consumption and the runtime went up:

I don't see any other change in the changelog that could have caused this as they seem to be more in the "Engine"-area...

@AnnaSasDev: Are you sure, that ValueTask is indeed faster/better in this scenario?

[AnnaSasDev]

I've reviewed all the AssertCondition methods I could find in the library, and they already complete synchronously without requiring asynchronous behavior. A few updates ago, the original synchronous implementation was changed to allow GetResult() to return Tasks (see: #1724).

Given that nearly all occurrences of these methods do not require asynchronous completion, I proposed switching from Task to ValueTask. This change should, in theory, be beneficial, as ValueTask avoids unnecessary allocations when the result is already available.

That said, I'm not an expert on the entire codebase, and as I stated in the original post I acknowledge there may be implications I haven't considered. However, based on my findings, converting these methods to ValueTask seemed like the better approach.

Out of curiosity, what was the last version you used before running this benchmark? That might help me investigate further. On my codebase, I don't see the same degredation in speed and memory usage, but that could be because of a lot of reasons.

[vbreuss]

I ran them now against v0.12.25 and v0.13.0:

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Bool_TUnit (v0.12.25)	922.6 ns	13.38 ns	12.51 ns	0.1459	-	2456 B
Bool_TUnit (v0.13.0)	835.8 ns	4.68 ns	4.15 ns	0.1421	-	2384 B
Equivalency_TUnit (v0.12.25)	654,766.1 ns	3,461.30 ns	3,237.70 ns	49.8047	0.9766	836953 B
Equivalency_TUnit (v0.13.0)	658,207.2 ns	2,707.94 ns	2,533.00 ns	51.7578	2.9297	866721 B
Int_GreaterThan_TUnit (v0.12.25)	1,257.1 ns	16.04 ns	15.01 ns	0.1793	-	3024 B
Int_GreaterThan_TUnit (v0.13.0)	1,137.4 ns	8.54 ns	7.99 ns	0.1755	-	2952 B
ItemsCount_AtLeast_TUnit (v0.12.25)	16,125.0 ns	149.20 ns	132.26 ns	1.6174	-	27528 B
ItemsCount_AtLeast_TUnit (v0.13.0)	14,203.6 ns	55.47 ns	51.89 ns	1.6327	-	27456 B
String_TUnit (v0.12.25)	1,350.9 ns	13.11 ns	12.27 ns	0.1869	-	3136 B
String_TUnit (v0.13.0)	1,276.1 ns	4.67 ns	4.14 ns	0.1831	-	3064 B
StringArray_TUnit (v0.12.25)	2,793.3 ns	12.27 ns	10.88 ns	0.2594	-	4352 B
StringArray_TUnit (v0.13.0)	2,691.0 ns	13.45 ns	11.92 ns	0.2670	-	4520 B
StringArrayInAnyOrder_TUnit (v0.12.25)	7,002.7 ns	33.18 ns	31.04 ns	0.4807	-	8152 B
StringArrayInAnyOrder_TUnit (v0.13.0)	7,074.1 ns	22.65 ns	21.19 ns	0.5188	-	8800 B

The difference is not so big, but there seem to be some side effects (especially when using equivalency and also for string arrays) where the changes seem to have degraded performance!

[thomhurst]

Wonder if it's the copy cost of structs being passed by value instead of reference? In all honestly I never quite understand when they're best to use or not.