@eizenhorn
Hmm this is interesting. But for some reason, I can not replicate your results.
My package got following code
internal static void GetKeyArray<TKey>(UnsafeHashMapData* data, NativeArray<TKey> result)
where TKey : struct
{
var bucketArray = (int*)data->buckets;
var bucketNext = (int*)data->next;
int count = 0;
for (int i = 0; i <= data->bucketCapacityMask; ++i)
{
int bucket = bucketArray[i];
while (bucket != -1)
{
result[count++] = UnsafeUtility.ReadArrayElement<TKey>(data->keys, bucket);
bucket = bucketNext[bucket];
}
}
}
I replaced above with yours, reloaded scripts and restarted Unity few times.
Tried compare times of original with yours. But my results seems are not affected by the package change.
This just should apply to GetKeyArray right?
Unless my packages are not reloading after scripts reloading, saving and restarting Unity.
PS.
I think this whole current business with getting unique keys/values is just too expensive, for processing few thousands entries every frame.
Any thoughts?
Edit:
I have also updated timings, to be more clear.
Red stops shows repeating test. FIrst top tests are after Unity startup, so values may be high.
It looks like, sorting and getting unique values from burst job, makes huge difference.
But still even Unity gives me message, about package resolving, when changing package code, I see no significant differences between each (left/right) solution, when populated hash maps takes same time. I.e 430-440ms.
Updated test code
Just for comparison 10k elements, 3 test runs.
Edit 2:
It also appears, if putting GetArray into burst, that speeds up this twice.
1mln elements.
