Support int priorities in FastPriorityQueue

[BlueRaja]

ints are nearly always faster than floats. Given how popular this library has become, and how many people are using it for non-pathfinding applications, it would be nice to have another queue that supports int for people who don't need float

[dougmill]

I've actually switched to uint and ulong now. Signed values are inconvenient to work with sometimes, and I might need the extra range of 64 bits.

[BlueRaja]

Have you profiled this? My understanding is that uint is generally slower than int because the JIT isn't programmed to optimize it as aggressively (because it's not a CLS-compliant type), but I've never verified that myself.

In any case, using uint in APIs is highly discouraged because of CLS-compliance.

[dougmill]

I just now profiled it, and the results were mixed. Some times uint was faster, some times int was faster. int was faster more often, but the margin was never big.

In any case, performance is not among my reasons for choosing unsigned types.

I'm certainly not suggesting that you support uint instead of int, but it might be useful (especially if you get code generation working for it) to support uint in addition to int.

[Bedivierre]

Maybe you can add another class with two generic types (node and priority value) and comparison delegate (or second type must support eq, lt and gt operations). This can be a stupid idea but though

[BlueRaja]

@Bedivierre This already exists, and is what SimplePriorityQueue is built off of. Unfortunately it's ~10-15% slower than FastPriorityQueue in my pathfinding benchmarks because the JIT is not able to properly optimize the comparison

[pajama]

This would also help support determinism across hardware. Please consider using long to maintain precision.