-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Studio] Optimize FindLoopNoAcc #55
[Studio] Optimize FindLoopNoAcc #55
Conversation
In fact, this change may not be as fast. |
Would caching the results maybe be worthwhile? It could help if there are many repeated calls on the same Transform, maybe cache all child transforms in that case and re-check only if there is no match found in cache? I think I did something similar to this in a different plugin, maybe ABMX (edit: here). |
Thanks for the review.
There are more queries that return null because no object is found than queries that do not. Therefore, it would have been faster if child transforms could be cached and non-existent transforms could be determined faster. My method is caching the paths. I think the nice thing about this method is that the cached path may work for another transform search. |
I've come up with an idea to speed up Find a bit, so I'm going to experiment with it. |
Please review with this. I've tried to keep the scanning progress on multiple queries. Searches for the same name were about twice per character. The number of offspring varied by trasform: there were trasforms with 700 children and others with 70-90 children. Measured with a 200MB file with 20 characters. Frankly, it is ambiguous whether it is getting faster or slower. before:
after:
after2(current):
It was faster as far as I could see in the mono profiler, but I think the overhead is too large to be inaccurate.
after1: 4.19[s]
after2: 0.07[s]
before_MonoProfilerOutput_2024-02-17_18-43-32.csv |
My PC was the cause of the blurry numbers. before: ave:55:64[s]
after1: ave:53.68[s]
after2: ave:53.34[s]
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Someone else reviewed it on discord, you can have look if you want here.
In the data I checked, 30% of the queries are initially returned and the remaining 70% return null. |
However, recording all of the root's children conversely slowed it down. A _findStack was added to store the scanning status of children. |
I don't think there is room for optimization in a regular FindLoop. In this case, optimization was performed based on the following assumptions.
Since it is a series of calls from one parent function, 1 is a reasonable assumption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I agree that it's probably as good as it can realistically get without modifying the game code to avoid the need for FindLoop in the first place.
You're right that the return is small compared to the complexity of the code. It is dangerous to complicate the code if the changes are frequent or have a large impact area. |
Thanks for the merge! |
Slightly optimized FindLoopNoAcc.
Loading large scenes, which used to take 95 seconds, is now 90 seconds.
Please merge if it looks OK.
The optimization I have implemented is simple, it records the path where the object was found in a previous query and searches that path the next time there is a query with the same name.
About 30% of the queries fall into this category and are accelerated.
Seventy percent of the queries return null.
In addition, I added the ability to output the scene loading time to the log.