Skip to content
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

(Question) Improve performance using parallelism #126

Open
jrodrigv opened this issue Oct 26, 2018 · 3 comments
Open

(Question) Improve performance using parallelism #126

jrodrigv opened this issue Oct 26, 2018 · 3 comments

Comments

@jrodrigv
Copy link

jrodrigv commented Oct 26, 2018

Hi, this is just a question/brainstorm.

Is there room for performance improvement by means of creating a pipeline where modules/patches can be somehow processed in parallel?

Kind Regards

@blowfishpro
Copy link
Collaborator

Processing patches in parallel could be messy since certain patches may rely on other patches having been run before them. Maybe you could work something out here but it would be complicated.

What I am working on right now is for ModuleManager to run on a separate thread while KSP is still loading models and textures. I think this is somewhat safer since patches are still applied sequentially and they only need to be done before KSP starts compiling parts.

@jrodrigv
Copy link
Author

Thanks for the answer @blowfishpro.
I think that should improve the performance.

I was thinking that it might be possible to perform a pre-processing of the patches in order to define a tree of dependencies and then process them in different threads but limiting the order between two specific patches if they depend on each other.

@blowfishpro
Copy link
Collaborator

blowfishpro commented Oct 26, 2018

One of the biggest complications is that there's actually a syntax for modifying things outside of the current node you're patching. Might be doable with some locking, but it would be pretty complicated to implement. There's still a lot of lower hanging fruit as far as optimization is concerned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants