When I add Astar game object to my project and enable cache startup, Unity begins to run very slow or even crash with out of memory exception.
Generated graph has size 1024*1024 nodes with node size ~1.46. Other settings are default. Cahe size for this grid ~4.6 Mb.
Why it can be?
Hm, not sure. Unity should be able to handle 4.6 mb data. The data is just stored as a byte array and if it isn’t changed, it shouldn’t be reserialized by unity. Are you possibly using another plugin which changes the scene a lot (and therefore might use the Undo.RegisterSceneUndo method in Unity).
Wow, it was really fast answer! As far as I know there is no other plugins. I created some test project to illustrate bug (here). Unity begin slowing down when AStart game object are in inspector window.
I am experiencing the same issue. My cache is around 3.5 MB, and map size 6734 x 6734 samples. It takes several seconds for the Inspector to refresh the “Astar Path” component – for example if you click on an element in the Inspector, it takes 3-5 seconds to highlight.
If I clear the cache, the slowdown disappears (although it takes 10-15 seconds for the slowdown to stop after clearing the cache).
This is with version 18.104.22.168 running on Unity 4.3.4.
Did a bit of investigation into this – the culprit is indeed:
Undo.RecordObject (script,“A* inspector”);
Not sure why this is causing such a slowdown, but if I comment the above line out, the slowdown disappears. Doing an Editor Profile showed the “Overhead” being 3+ seconds, but even with a Deep Profile the Overhead wasn’t broken down.
Same issue for me. Alan, did you fix the problem? I tried commenting out that line in the AstarPathEditor file but I’m still getting the slowdown.
Note: Even during runtime, trying to load the cached data for a scene takes about 20 seconds, even though it’s only 27Kb.
Sigh. Ok, so Unity has deprecated the old Undo API which actually worked.
What I believe RecordObject does is that it saves the state of the object every single frame (but only for a short while if it doesn’t change). Since I am saving several kilobytes (sometimes megabytes) in the editor, that is what slows it down.
The best workaround right now I think is to save the graph to a file instead of using Cached Startup. That will get you the same behaviour, but it is more tedious.
Hm, so you are still getting the slowdown. That’s odd. Do you think you could send me a small reproducible example which I can take a look at and debug?
PS: Sorry for the late answer, I have been away for a while and haven’t been able to answer many forum posts.
Oops, sorry for the late reply @aron_granberg — I don’t think I got an email of your reply.
I have just installed the new version and will give it another try soon and let you know if I still have the cached data slowdown.
I have been waiting several months to upgrade in the hope this issue was fixed. I have just updated to the newest version, and while the initial scan only takes about 20 seconds when generating cache, it then hangs unity for 5+ minutes (several times) before I killed it (as it did prior to the upgrade).
I have tried commenting out the Undo line noted above and this doesn’t seem to resolve the issue. Out of curiosity I will probably let it run while eating dinner tonight to see if it completes in any reasonable amount of time (I tried this before, and it took something like 18 hours to complete after it had finished scanning).
As a workaround, save the graph to a file and load it directly at start. That should give you the exact same behaviour but without the slowdown. See http://arongranberg.com/astar/docs/save-load-graphs.php for some code snippets.
When I fix this, I will probably do it by adding a field for a file to be loaded at startup as I haven’t been able to find a proper workaround for the slowdown when the data is stored in the editor.