koobas.hobune.stream
Editor Scripts running slow
Hello,
I have a lot of scripts that I use to setup stuff in the editor. Mostly CustomEditors. When designing these scripts I am not as much paying attention on whether they are written in the most performant way (like they calculate a value twice where I could just calculate it once).
But even thought that there might be a couple small things I could improve, I still think they should not be stuck somewhere for a long time. When I calculate some stuff it seems to take forever (sometimes a couple minutes for a few thousand calculations).
Is there anything special to pay attention in the Editor?
Like are there any calls I should avoid?
@fred_gds There are tons of stuff to avoid in Unity. This is a good introduction to the topic.
I don't know if that article brings it up, but the default comparer for Vector3 (Vector3.Equals()) creates a new Vector3 when it is called. So it is a really bad idea to loop that several thousands of time (a giant garbage generator).
When I worked on pre-processing A* paths I retrieved 22k paths in a couple of $$anonymous$$utes (that's 1-15000 iterations for each path).
You should really post your code so we can help you.
Thanks for your suggestion and the article.
I definitely use a lot of the Vector3.Equals() which might cause the problem. I'll definitely check on maybe calling the garbage collector at key points.
$$anonymous$$y code is kind of long and on multiple scripts so I think it would be way too long to post it here (and it is not that well documented :D ). I just hoped to get some general advise as your suggestion on comparing Vector3 :)
"Another interesting side-effects of the List type is that, even when it’s cleared, it does not release the memory it has allocated (ie. the capacity remains the same). If you have a List with many elements, calling Clear() will not release this memory – it will just clear out its contents and set the count to zero. Similarly, adding new elements to this list will not allocate new memory, until capacity is reached." from the article is definitely a great advise
@fred_gds Yeah. I don't know if the article brings it up but you should always type in an estimated size of the list() (it would look like ... new List<myClass>(1000);. The resize of a list is extremely expensive. What it does is that it creates a new array with a new size and copies all the elements into the new array. This means that nothing will reference the old array any more and it will become garbage.
If you're working on a grid-based position system you can bitshift each of your vector3-components (x,y,z) into a single ulong. This will make it possible to compare them without the memory problems. This may or may not work depending on the size of your positions as well.
