BFS Path Finder

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

I don't see the point in serverPathConstructOnIteration, serverPathCoroutineDispatcherThreadLocal & serverPathCoroutineDispatcherConstruct

---

The point of them is to see what kind of performance you'd get with different implementations

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

Surely you wouldn't recommend creating a path finding instance for each search or sharing one between multiple coroutines, so what's the benefit from benchmarking them?

---

serverPathCoroutineDispatcherThreadLocal uses [Only registered and activated users can see links. Click Here To Register...]
serverPathCoroutineDispatcherConstruct constructs a new SmartPathFinder per coroutine

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

Also I don't think serverPathCoroutineDispatcherThreadLocal is working, it's probably just resetting the instance 2k times then calculating the path once?

---

Not sure what you mean by this. Where would you get the idea that it "resets" the instance 2k times but doesn't calculate the path 2k times (both handled in findPath).

Quote:

---

Originally Posted by Tomm0017 [Only registered and activated users can see links. Click Here To Register...]

The point of them is to see what kind of performance you'd get with different implementations.

---

Ugh yeah I'm assuming that creating an instance each time will be slower than reusing a single instance based on intuition not data

Quote:

---

Originally Posted by Tomm0017 [Only registered and activated users can see links. Click Here To Register...]

serverPathCoroutineDispatcherThreadLocal uses [Only registered and activated users can see links. Click Here To Register...]
serverPathCoroutineDispatcherConstruct constructs a new SmartPathFinder per coroutine

---

Per thread, but yeah I was thinking it's based on the assumption that each coroutine will run sequentially in it's thread, but you're right that is the case in this scenario.


The other thing to mention is you're not including the cost of copying the data from the collision data to the clipped map, and then you could also compare that and not using a clipped map at all.

If you're really worried about performance, here's some other ways to optimise or to test if they perform better:

• Directions & distances arrays can be combined into one
• ringbufferX/Y can be combined into one
• The "max turns" can be included into the backtrace
• Remove the path array creation and reuse it/pass it in as a parameter
• Arrays.setAll can be replaced with keeping track of visited tiles (although scu argues that it's a cheap call, I see 1-5% performance increase from it, definitely an over-optimisation though)

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

The other thing to mention is you're not including the cost of copying the data from the collision data to the clipped map

---

This is pointed out in the [Only registered and activated users can see links. Click Here To Register...]

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

and then you could also compare that and not using a clipped map at all.

---

The benchmarks are using real collision data. They are just preloaded via the resource files instead of being copied on demand.

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

If you're really worried about performance, here's some other ways to optimise or to test if they perform better:
...

---

Thanks, will keep the list handy. For now, the performance is fine. If in the future I want to add features that will hit perf, I'll look into this. (y)

Nice contribution <3.

Quote:

---

Originally Posted by Tomm0017 [Only registered and activated users can see links. Click Here To Register...]

The benchmarks are using real collision data. They are just preloaded via the resource files instead of being copied on demand.

---

I mean instead of taking a 128x128 clipping of the collision data and searching with coordinates 0-128 you can just call the original data directly using the original coordinates, removing all the copying and the baseX/Y. It in theory would be slower but in practise doesn't seem to make much difference and significantly simplifies the code

Quote:

---

Originally Posted by Greg [Only registered and activated users can see links. Click Here To Register...]

I mean instead of taking a 128x128 clipping of the collision data and searching with coordinates 0-128 you can just call the original data directly using the original coordinates, removing all the copying and the baseX/Y. It in theory would be slower but in practise doesn't seem to make much difference and significantly simplifies the code

---

Don't see it being worth the hit just to use "real"/in-game coords within the internals of the lib. Copying 128x128 clipping flags shouldn't be such an intensive task to warrant it.

Quote:

---

Originally Posted by Tomm0017 [Only registered and activated users can see links. Click Here To Register...]

Don't see it being worth the hit just to use "real"/in-game coords within the internals of the lib. Copying 128x128 clipping flags shouldn't be such an intensive task to warrant it.

---

Yeah the performance difference is minor compared to the benefit of simplifying the code imo