Performance issue when having vessel with multiple MechJeb parts
Faark opened this issue ยท 9 comments
Hey guys,
i recently wanted to carry a bunch of RT satellites into orbit with a single launch. They all have MJ for lazy orbit corrections, that makes 10x MJ in total. Thanks for that awesome tool, btw. Anyway, turns out the frame rate for those sat carrier is horrible and it is caused by MJ.
To verify this i made a copy of AR202 part cfg with both MJ-PartModules removed and this helped me to get a mostly green frame rate.
I tried some profiling to help figure out the source. The timing of that self made tool I used to do so isn't very reliable, but i think its mostly caused by GetMasterMechJeb. It both doesn't scale very well for large part counts and is called ridiculously frequent, for each additional MJ. You might want to switch to that sth scales nearly o(1) / a local var that is updated once per frame&vessel? I also don't get why FlyByWire have to be called for each of the disabled MJs, but again the slowdown is because of GetMasterMechJeb. I'll add the reports in case you want to study them in detail.
Everything mentioned above can be found in the following Google-Drive directory: https://drive.google.com/folderview?id=0B-ewfC7WBS6aTnJqWFpwS0pGLW8&usp=sharing
Other info:
- This report is based on today spaceport MJ copy, Though i also tried a recent dev channel build as well and could not notice any performance difference.
- See logs for computer specs
- All Mods: MechJeb, NavyFish, RemoteTech2 (modified), TriggerTech
Thanks for reading, hope you can improve it & keep up that awesome work!
Faark aka Dirk
A bug report with all the needed info and info about the code problem ! :)
I'll look into it, some caching makes sense.
Could you share what you made for profiling too ? That would be useful (I wish I could use all the cool tools I have at work on KSP...)
Not sure how useful it will be, but the current "unpolished" state is already online: https://github.com/Faark/AssemblyBasedProfiler
Ah, bytecode modification. Just like the tools I use (I sure could not write one like you did :p )
Looks quite useful already even with the few current limit you specified in comments. I had a user complain of large slow down with specific mods so I'll look into it with that.
Ok I have something.
Forgot to reference the bug in the commit message ...
I did a quick test with your profiler but compiling with VS don't seem to be the greatest idea I had(Invalid IL code on runtime).
My code should be better anyway, so could you test build 108 and give me feedback ? thanks
http://jenkins.mumech.com/job/MechJeb2/lastSuccessfulBuild/artifact/jenkins-MechJeb2-108/MechJeb2.dll
The editor issue? Thanks, was just trying to test it... in flight performance appeared much better on a first look.
The exception in editor is silenced, but MJs stuff still isn't working in there.
New profiling data for 108: https://docs.google.com/file/d/0B-ewfC7WBS6aUHpaX2EtVy1JYWs/edit
As expected does the in flight performance look indeed much better, now. Even when having just a single active MJ does the new lookup save a little bit. Now it is definitively fine for me, so more invasive changes should not be necessary, unless someone starts flying vessels with a 4 digit part count^^
About the profiler: I will polish it somewhat, add a manual and leave you a note once its done.
What byte code based tools are your using? Just asking so i do not reinvent the wheel... again :)
A little offtopic, but it took me a while to figure out that the new version's features are unlocked by tech ranks (my per-performance-investigation version obviously did not). Where are those unlocks handled? I haven't found any code relating to this...
One more bug to fix then
I work with java performance analysis tool that does the bc modification for me, I don't deal with it directly.
It's coded in the part.cfg, look at the module definition.