Do you make a system call or call to a library function in there?

Edit:

Nvm, guess I can look.

EditEdit:

Or not. Where is VoxelTree? Oh, you linked it wrong, but I can just navigate to it. : p

Gonna guess that it's this:

BoundingBox b2 = new BoundingBox(Voxels.Values.ElementAt(i).Position - Vector3.One * vSide * 0.5f, Voxels.Values.ElementAt(i).Position + Vector3.One * vSide * 0.5f);

Can you break that out into a separate function and call it there, then check the profile again?

I'm wondering if it's the allocation is why I singled that out. I don't see any other external calls in that function, but I'm kind of sleepy as well.

BoundingBox is your code, so I would expect it to show up in your call stack if it were the problem. And it's a struct, so it shouldn't be causing any heap allocations.

I would focus maybe on the dictionary values enumeration. Isn't there a setting that will show you symbol information for system calls? I know there is for viewing the callstack in the debugger, I don't know if there is for the performance stuff...

You're calling ElementAt four times, it seems you should be able to just call it once and store the result.

I don't see anything obvious in that function that would be causing any heap allocations (and possible performance issues), but .net can be sneaky that way.

Ok, it looks like (from my own tests) calling ElementAt on the Dictionary's Values collection is really slow. I'm guessing it is an order-n operation that needs to iterate through items one by one, since the larger the index the longer it takes.

You probably want to use foreach instead (and hopefully the ValueCollection's iterator is a value type, to avoid unnecessary heap allocation)

In the little test I did, for a Dictionary of 10,000 items, this:

Agreed that struct doesn't necessarily mean it's allocated on the stack, but in the OP's usage scenario it will.

You basically have:

    public struct BoundingBox : IEquatable<BoundingBox>
    {
        public Vector3 Min;
        public Vector3 Max;

        public BoundingBox(Vector3 min, Vector3 max)
        {
            this.Min = min;
            this.Max = max;
        }
    }

and then in the function:

    BoundingBox b2 = new BoundingBox(Voxels.Values.ElementAt(i).Position - Vector3.One * vSide * 0.5f, Voxels.Values.ElementAt(i).Position + Vector3.One * vSide * 0.5f);

In this case, the new is not allocating on the heap. I looked to see somewhere that b2 might be boxed (say, by an implicit cast to IEquatable<BoundingBox> ), and couldn't find any.

Ok, it looks like (from my own tests) calling ElementAt on the Dictionary's Values collection is really slow. I'm guessing it is an order-n operation that needs to iterate through items one by one, since the larger the index the longer it takes.

You probably want to use foreach instead (and hopefully the ValueCollection's iterator is a value type, to avoid unnecessary heap allocation)

In the little test I did, for a Dictionary of 10,000 items, this:

for (int i = 0; i < blobs.Values.Count; i++)

{

value += blobs.Values.ElementAt(i).a;

}

was more than a 1000x slower than this:

foreach (Blob blob in blobs.Values)

{

value += blob.a;

}

Just a FYI:

Dictionary, List, possibly a few others (except for Collection<T>) all have struct enumerators and explicitly implement the GetEnumerator() so the GetEnumerator that actually will be called in that foreach will return the struct enumerator and not do any boxing.

With that said though, ElementAt is an extension method for IEnumerable<T> so the value collection is going to be treated as an IEnumerable<T> and the explicitly implemented GetEnumerator will be called, which means the struct enumerator will be boxed.