-
-
Notifications
You must be signed in to change notification settings - Fork 316
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
Improve performance of autoedges #739
Labels
Comments
@frebib If you could push (even a non-compiling) POC of your autoedges branch, that would be awesome! |
A bit more data to be sure
|
I haven't worked on this since the cfgmgmtcamp hacking day and I only just made it compile. No idea if it works, but have at it: https://github.com/frebib/mgmt/commits/frebib/autoedge/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Autoedges is not as fast as it could be. It's not blocking us anywhere, but we should think about eventually optimizing this to lower graph sync latency.
Analysis
For each new resource graph (in the stream of resource graphs) that is generated, we must compute the automatic edges. I ran this on my provisioning code base. (It will be published shortly.) Currently this is a bit slow. I added some light profiling to the graph generation steps, and I got the following:
Note the units. What surprised me was that I expected autogrouping to be the slower operation, but in fact it is not. This is obviously highly dependent on the specific
mcl
code being run, but it gives us a good rough idea.Improvements
There are both algorithmic improvements and plumbing improvements that we could do.
Algorithmic
@frebib has some initial POC work on making the algorithm n*log(n) IIRC. I think it's currently n^2.
Plumbing
There are likely some efficiency wins if we look at the code. This needs proper profiling (even flamegraphs?) to know where we're actually slow.
We could also consider adding a static API at resource creation, that defines which resource kind pairs are even legally able to create auto edges. For example, if we know that
svc
can only ever autoedge withfile
andpkg
, this reduces our search space drastically. Keep in mind that either resource side needs to be able to opt-in.Concurrency
Graph generation happens in parallel to execution, so this isn't blocking execution. We could double-check that it's nominally concurrent, and we could make sure we pause only after the graph is built, but this is very low-priority. Secondly, I wouldn't be surprised if we could actually implement a concurrent version of the autoedges algorithm that uses more CPU's, but I don't think this is an important optimization to do at this time.
Generics
@frebib believes the algorithmic implementation would be a lot faster with generics. If we can avoid this, that should be a goal, but it's an important thing to discuss.
The text was updated successfully, but these errors were encountered: