[Bug] Hyperspace lag when transitioning between systems when compiled using the debug profile

[Zitchas]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When hyperjumping from one system to another, at the point of transition there is a brief lag when everything freezes for a moment before arriving in the new system and motion starts again. By brief I mean about half a second or so.

Steps to Reproduce

1. Compile the game under the debug profile
2. Created a new pilot
3. Buy ship.
4. Leave planet and hyperjump
5. See error

Expected Behavior

Expected behavior is that which we had in v 0.10.6 and earlier: Seemeless transition without pauses or freezes when he travel from one system to the other, regardless of compiling profile.

Screenshots

No response

Link to save file

No response

Operating System

Windows 10 Pro

Game Source

Built from source

Game Version

Delta, latest upstream, and a variety of points in the past.

Additional Information

Tested setups (same pilot in all cases):

• v 0.10.6 release download from Github: No lag
• self-compiled debug build from a branch circa the time of the v 0.10.6 release: No lag.
• downloaded artifact from cloaking variation implementation PR: lag.
• self-compiled latest debug Delta build (fully up to date with upstream): lag.
• Used git to check out PR feat(mechanics): Pit boarding attack against boarding defense #10060, debug compiled it: lag
• Used git to check out PR feat(balance): Rebalance turret turn rates for consistency, and apply a global nerf #10043, debug compiled it: lag
• Downloaded exe from PR feat(mechanics): Pit boarding attack against boarding defense #10060 artifacts, won't even run. (will run once I replace the dlls with a fresh downloaded set): no lag
• Switched to "release" compiling
• self-compiled release version of 10060: no lag
• self-compiled release version of Delta: no lag

Based on this, it appears that something has changed in how VS compiling the debug version is handled. Everything previously compiled locally under the debug profile and run just fine. I can still compile and run branches from circa v 0.10.6's release date and they run fine; but anything recent and after I compile them they lag when compiled in debug; however they do compile fine when done in "release" profile.

[danaris]

Have you checked whether the "extended jump effects" preference setting is different between these?

[warp-core]

I suspect this is a result of conditional links.
However, if the lag is only apparent when built for Debug, I'm not overly concerned.
The Debug build is expected to have worse performance than the Release build. Though, a noticeable decrease in performance in Debug may indicate a similar penalty in Release, as well. But, if that isn't apparent, it's not really a problem. It's difficult to do more things without consuming more CPU time.
It is curious that you encounter the lag on the CI artifacts, though, since those are supposed to be built in the Release configuration.
It would be useful to know about the hardware configuration of your computer. Are we talking about noticeable lag in Debug on a 15 year old, ultra low power CPU with memory slower than a USB drive, or a brand new, top of the line extreme gaming desktop?

Edit: also, which artifacts were you downloading from each PR? The CI (only gives the executable, no game data) or CD (the full package you would download from the release page)?

[Zitchas]

Have you checked whether the "extended jump effects" preference setting is different between these?

Yes; I tried alternating through all three settings (Medium, Heavy, and Off).

It would be useful to know about the hardware configuration of your computer. Are we talking about noticeable lag in Debug on a 15 year old, ultra low power CPU with memory slower than a USB drive, or a brand new, top of the line extreme gaming desktop?

Somewhere between those two extremes. Neither a 15 year old low power CPU, nor a brand new power guzzler:

• AMD 3800X
• 16 GB DDR4-3200Mhz
• Endless Sky is running from an SSD

Edit: also, which artifacts were you downloading from each PR? The CI (only gives the executable, no game data) or CD (the full package you would download from the release page)?

The download from the cloaking variation was the full CD; while the Boarding combat one was just the exe (so the CI). I downloaded a third, but I forget which one it was at this point. (and the artifacts don't have much in terms of identifiers)

[warp-core]

Testing with a couple of laptops, one has an Intel 7200U, the other has an Intel 5300U. (Both being faster than the first computer I played Endless Sky on, with no issues.)
The pause is clearly visible when built with Debug on both systems.
On Release, there's nothing significant enough for me to notice it.

[Zitchas]

Thanks for testing. That seems like a confirmation that there's a bug with the way the debug is compiled.

Based on my own observation, a change that was pushed to the repository since the 0.10.6 release; since I can still build that and prior branches in debug with no problems.

[warp-core]

It's nothing to do with any change to how it is compiled. It's additional computations introduced by the conditional links feature.

[warp-core]

I've done some more testing, this time, measuring the time spent in the call to GameData::UpdateSystems from Engine::EnterSystem introduced in the conditional links PR. I also tested the 7200U laptop at power settings other than "best performance".

In particular, I noticed that the lag on departure and system transition is noticeable when the laptop is on a power mode other than "best performance" on Release, which is a problem.

Build target	5600X	7200U best performance	7200U better performance	7200U better battery
Release	~40 ms	~80 ms	~120 ms	~220 ms
Debug	~200 ms	~320 ms	~360 ms	~500 ms

Notably, even my desktop can't handle the frame involving EnterSystem in under 1/60th of a second, requiring ~1/25th of a second. Though a single 40 ms lag is too fast for me to notice.
And, while I also can't notice the ~80 ms lag on the 7200U at "best performance," the lag at "better performance" is visible, though possibly only because I'm looking for it. Others' experience may vary.

I also tested the time spent in Engine::EnterSystem on the commit prior to conditional links.
My desktop gets about 2 ms, while the laptop varies between 4 and 20, mostly around 10 ms.

A way to make this more visible is to add more systems.
So, I installed the Galactic War plugin. It adds many systems.
In 0.10.6, there was no discernible lag on my desktop.
After conditional links, taking off or jumping between systems involves a pause of 7 seconds when built for Debug or 2 seconds when built for Release.

[Amazinite]

The issue is that the conditional links PR makes the game recalculate the linkages between every system every time the day changes. This is an O(N^2) operation with a sizable N, especially if you have plugins that add a lot of systems.

I think that conditional links should be changed to behave differently. Instead of conditional links requiring that you have the conditions in order for the link to exist, a conditional link should be a link where you need to have the conditions to use it. This way we're not recalculating every link in the game every day, as the link always exists. Instead we would be calculating if you can use a link at the moment that you are attempting to use it, which is a much cheaper operation.

[Zitchas]

I do rather like what the conditional links is trying to achieve, and it's not quite the same thing as having permanent links that require specific conditions to use (unless not having those conditions makes the link invisible?)

This seems like it might be a good opportunity for some multi-tasking. As in, during the course of a hyperjump the player is locked into a specific animation that takes a bit of time. Likewise for Jump Drives. Might it be possible to have the recalculation process "lock-in" the link that the player is currently taking, and start recalculating all the rest of the links in the background while the player is stuck in the animation; and then "unlock" the link they just used when they reach the destination system and recalculate that link at the end of the jump?

[Amazinite]

Note that the question of whether the link exists is not the same thing as whether the link is visible and usable. We could easily make it so that links that are not usable are also not visible, which to the player might as well mean it doesn't exist.

Calculating which links exist is expensive. It will always be expensive, and throwing more computing power at it is only delaying the inevitable. Therefore, the existence of links should be calculated as little as possible.

[Zitchas]

Sure.

Seems like there's really four potential states:

1. Usable and visible
2. Unusable and visible
3. Unusable and not visible
4. Usable and not visible. (I would expect this one to be very uncommon, but useful for certain specific sorts of challenges)

Both the usability and visibility would be controlled by various conditions that generally don't change except when missions end or start, or outfitting changes. So that seems the point where calculations should happen. While people are staring at outfits, watching the hyperspace animation, watching their ship land/take off... There's a variety of points where the player is just watching an animation, and anything the game needs to calculate could be done during these parts to the degree possible.

[petervdmeer]

The issue is that the conditional links PR makes the game recalculate the linkages between every system every time the day changes. This is an O(N^2) operation with a sizable N, especially if you have plugins that add a lot of systems.

I agree that this is a problem.

I think that conditional links should be changed to behave differently. Instead of conditional links requiring that you have the conditions in order for the link to exist, a conditional link should be a link where you need to have the conditions to use it. This way we're not recalculating every link in the game every day, as the link always exists. Instead we would be calculating if you can use a link at the moment that you are attempting to use it, which is a much cheaper operation.

I prefer a solution where we have conditional links appear and disappear (as is done in the now-reverted implementation) without the performance impact that came with it. (Not sure yet how difficult it would be though.)