Memory allocation number is unacceptable and library author ignoring the concerns about astar

[roy-t]

Hey, great that you put so much work in finding the places that could be improved. I closed some old issues about a year ago because I thought nobody was interested anymore.

As I commented in #9 there are no allocations on the heap in the search algorithm. Only the utilities around it allocate. But they mostly Allocate short lived objects, that the compiler/gc can easily reason about. But these things could indeed improve.

But I don't want to slavishly work towards less allocations unless if it is giving problems. Zero allocations, like all performance optimizations shouldn't be done prematurely. And should only be done where it matters.

Do you have any problems, what is your use case, how are you using the library?

(In my own use case I search for paths on a separate thread, long paths but only a handful per second. In this case I don't notice any problems. I can imagine that in other use cases the code might not behave so nice. We can fix that!)

[mikkleini]

You can DIY and create a pull request...

[roy-t]

Closing because of no response, and I'm working on a big refactor that will probably also alleviate some of these issues.

[JoNMii]

How is the state of this issue? It is eatinng literally TONS of memory just for one 600x600 grid with only lateral movements enabled.
Thanks

[roy-t]

@JoNMii as far as I know there are no outstanding memory/performance issues with this library. But I'd be happy to improve things if someone show's me a case where the code behaves badly. As I care a lot about performance :).

I can't really do much with the comment 'TONS'. Is the memory used increasing more than you expect? For example I would expect a 600x600 grid to use 4x as much memory as a 300*300.