Spoiler
Still not definitive, but here's some more data:
Baseline, flying around with no slowdown, I see:
54% of time is in com.fs.starfarer.campaign.CampaignEngine.advance()
35% of time is in org.lwjgl.opengl.Display.update()
7.5% of time is in com.fs.starfarer.campaign.CampaignState.render()
With slowdown, the breakdown is instead:
54% CampaignEngine.advance()
25% Display.update()
14% CampaignState.render()
Hm. Looks like there's something suspicious under CampaignState.render(). Let's break that down another level.
Baseline, no slowdown:
com.fs.starfarer.campaign.CampaignEngine.render(): 3.2%
com.fs.starfarer.ui.interface.render: 3%
and a few other smaller things make it all round up to 7.5% total for CampaignState.render.
With slowdown:
com.fs.starfarer.ui.interface.render: 8.6%
...Okay, so it looks like whatever the problem is, it's something to do with UI rendering? (Trying to track the stack traces down further did not, unfortunately, yield any further information or any sort of obvious smoking gun.)
This was, again, a slowdown triggered after end of battle. Though, with your comment on invisible tooltips hanging around, I'm wondering if there's a way for such a thing to be generated by an end-of-battle collection screen or something? Looks like I may need to do memory sampling in addition to CPU sampling... but not tonight. This morning? Whichever; I need to get some sleep.
First off, thank you for doing this! Hmm.
This actually doesn't seem right. A couple percent difference in the time spent rendering is not going to affect the framerate in a way that's even detectable, let alone bring it down that much. The time spent in Display.update() is mostly time spent sleeping waiting for vsync. The time change spent in render() is probably due to a relatively different amount of time spent waiting for vsync() due to the advance() method taking longer than a single frame's time and changing how all that lines up.
Besides, even with the slowdown, you're looking at rendering being by far the smallest of these three. The data doesn't make too much sense, though, but I'm pretty positive that what it doesn't point to is a UI issue. To me this just looks... strange, like some pieces of the puzzle are missing, or the sampler didn't run long enough, the game was paused/inactive while sampling, the sampling itself affected the distribution (that's always fun), or *something*. Basically, I'd expect to see something more pronounced given the conditions under which the samples were taken, and it's not there, so we're missing something.
Also, the tooltips issue wouldn't just happen like you're thinking - it'd take some time, and iirc was refit-specific. It's basically a red herring for 99% of the cases, not something many people would run into or be noticeably affected if they did.
It'd be interesting to see the data from a screenshot of jvisualvm/visualvm, if you have that. Some thread dumps would I think also be informative.