Removal of FastCollections

[IXLLEGACYIXL]

currently we have fast list , fast dictionary , fast list struct which is overcomplicating stuff as it can be replaced with normal collections anyway

1. are these collections actually fast?
2. are these even needed?
3. does anyone know when to use them anyway? havent seen them being used in a recent PR

also they are a source of potential bugs

[Jklawreszuk]

1. Would be cool to analyze whats the difference between list vs fastlist, dictionary vs fastdict and perform simple benchmark tests
2. Yes, they are. These collections are strongly related to the engine. The question is whether they are actually "fast", because we haven't visited quite long time.
3. Practical use : TrackingCollection.cs or Entity.cs

[Eideren]

Looks pretty good, the last thing one would have to test is whether iterating over var items = FastInts.Items; is faster than iterating over a list.

[Doprez]

ahhhh ok, good call.

Added the below tests

[Benchmark]
public void TestUnderlyingArrayFastList_1000()
	{
for (int i = 0; i < 1000; i++)
	{
		FastInts.Items[i] = i;
	}
}

[Benchmark]
public void TestUnderlyingArrayFastList_1000000()
{
	for (int i = 0; i < 1000000; i++)
	{
		FastInts.Items[i] = i;
	}
}

So it looks like there is a decent difference between the two when you actually access the underlying array.

[Eideren]

Right, but now we have https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.collectionsmarshal.asspan which does the same thing for List<T>, so I think we can deprecate FastList and replace calls to FastList<T>.Items with AsSpan above.
We can close this discussion and open an issue with those findings, and/or create a PR if anyone wants to take over.

[Doprez]

I guess the work would to be first add the deprecated attribute to the FastList with a recommendation and then start working through replacing them throughout the code eh?

[Doprez]

holy cow yeah, this is beautiful.

[Basewq]

I think there was only one real reason for them which was implementing struct Enumerator.
The standard collections have class enumerators, so foreach always allocates objects. There's been a few posts in the past with XNA/Monogame/Unity how you must avoid the standard collections because of this (or only use for (int i = 0...)).

[Eideren]

Looks like they've always been structs from Framework 2.0 onwards: https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.list-1.enumerator?view=netframework-2.0

[Basewq]

Hmm, I must be forgetting some of the details then...
I think the advice might have been when interacting linq code (which pushed the class up to IList or whatever), though I think that has been changed to use the struct versions when it detects the standard collections nowadays.

I do recall that Stride's FastList exposed the underlying array because it pushed it out to some graphics buffer or something, but that was the only 'fast' thing about it.

[Eideren]

FastList provides its backing array for read and write operations for example, which at the time was not something the BCL provided, now we have the collection marshal namespace providing unsafe access to it.
At the time those types were created collections were pretty awful performance wise. Dotnet has really been focusing on optimizing them since then, I doubt that ours would be faster than dotnet's but we'll have to run benchmarks to ensure that's the case before deprecating them.

[Kryptos-FR]

If I remember correctly, it was the main reason for creating those alternative implementations. At the time, if we had used the standard collection we would have had to ToArray() them forcing an expensive copy/allocation.

If it can be replaced with officially supported code, then we should indeed change that. We must be careful to properly list all usages to not introduce performance regressions.