great mod but less laggy perhaps?

[Valoneu]

any way to make the mod less laggy like its not lagging that much but yea

[DanielHeEGG]

I didn't notice much lag during testing, perhaps a mod interaction triggered it. Could you provide more details? Like the mod list you're using, etc.

[Valoneu]

its not like its super laggy its like +1ms

[DanielHeEGG]

1ms doesn't seem that bad. The code's pretty simple so it might be hard to further optimize, just a postfix might not do the trick. I'll look into it.

[5thHorseman]

I'm having the same problem. Mod enabled, 17fps/30ups. Mod disabled, 60/60.

With the mod enabled, i can also fix the fps/ups problem by not having any guns able to shoot, either by not giving them sails or not giving them a reachable target orbit. As soon as one gun with sails can target an orbit, though, I get the fps/ups hit.

I also use Railguns Retargeting, but disabling it while leaving SmartEjectors enabled does not solve the problem. Disabling SmartEjectors with Railguns Retargeting enabled, the game runs fine.

Not sure what other mods would affect it, but here's my mod list right from r2modman (some are dependencies):
BepInEx
CommonAPI
NebulaMultiplayerModApi
LDBTool
BlueprintTweaks
CruiseAssist
SphereEditorTools
BetterStats
SphereProgress
DSPAutoSorter
FreeCamera
DSPModSave
DSP_Belt_Reverse_Direction
AutoReverse
MinerVeinCoverage
DSP_Star_Sector_Resource_Spreadsheet_Generator
AssemblerUI
Bottleneck
No_Advisor
BetterWarningIcons
DSPOptimizations
RailgunsRetargeting
Planet_Vein_Utilization
AutoPilot
AutoStationConfig
UIEnhancements
SmartEjectors
BetterGlobeMap
LongArm

[DanielHeEGG]

Im failing to recreate the issue. Could you send your PC's specs and your save file (put it on a Google Drive and send me a link). While you're at it, send all the config files too so I can replicate the exact conditions.

[LordMike]

I'm seeing something similar. I get 30 frames-ish without this, and 10 with it. I'm using a few thousand ejectors in various systems to fill their spheres. I looked at the code, and I'm not sure how often "EjectorComponent"'s InternalUpdate runs, but if it's often, it can balloon quite a bit.

So on every InternalUpdate, IsSphereFilled and possibly also IsNodeLimitReached runs. In my case, with thousands of ejectors for the same system, I will be having the same calculation done thousands of times. Especially the IsNodeLimitReached seems heavy, as it has to enumerate every node in every layer for the sphere. In my case, I've filled the 16 layers with the same sphere layout which is "most economical" on DSP blueprints, so it has iirc 80 nodes.. Not a lot compared to other blueprints - but it still represents a great bit.

Especially if some of the properties are heavy to access.. F.ex. this code access both the layers by id, which could represent some computation to produce this list.. and then for each of those it accesses nodePool, which again, may require some code to run to produce it.

If I may suggest, an alternative approach would be to calculate the two states (filled & limit reached) for each system once every, say, 20 seconds. And then using those values to determine if a specific ejector should be locked or not. It probably does not matter if the "update rate" is 20 seconds, meaning it could be 20 seconds before ejectors stop or start firing again. Even if the update rate was 1 second, it'd probably be a huge improvement, as you're saving the computation needed for hundreds or thousands of ejectors. If the game has an internal tick counter, you could also cache the values of filled & limit reached, for each tick, such that the value is always up to date, but only computed once per tick.

[DanielHeEGG]

Thanks for the detailed info, I'll look into it.

[LordMike]

Just wanted to chime in that I confirmed this mod is slowing down my game immensely. I disabled all mods except the CompressSave/DistributeSpaceWarpers mods, in order to load the game, and then this mod, SmartEjectors. Additionally, BepInEx and NebulaMultiplayerModApi are loaded as dependencies.

Without SE, I got approx. 20 | 40 frames (i think the first is the game loop, and the second the draw loop), and with SE loaded it dropped to ~ 5 | 10

I created a share with my save file here:
https://1drv.ms/u/s!AneqKj2lKW4Uj_4TKCgJT5A8-6PMyQ?e=yu7LRj

There is also a file, Minimal_1673303090947.r2z, which I think can be imported into Thunderstore.

[LordMike]

I just realized you could make this even faster.

If you at first run calculate the number of solar sails places left for some Dyson sphere, you could then keep subtracting from that until you hit 0.

Interlocked.Decrement() can subtract a number, atomically, without concurrency issues.

In order to track how many sails can be absorbed at once, you could use a semaphore-like setup. Set it up with a number of allowed sails at once, and then subtract one every time you launch a sail. When sails then arrive, maybe that’s a function you could hook - then add one back to the semaphore.

The semaphore should be recalculated once in a while, such as when Dyson sphere planning changes.

Mike.

[DanielHeEGG]

Calculations now run once per game tick per sphere.

Given the same save file:
Performance for 1.3.2 was 16 | 32 and 29 ms CPU time.
Performance for 1.3.3 is now 27 | 57 and 17 ms CPU time.
For reference, SE disabled is 29 | 57 and 16 ms CPU time.

[linxuanm]

OH GAUD DANIEL IT TOOK YOU A WHOLE YEAR TO FIX THIS ISSUE
SHAME ON YOU SUCH BAD MODDER LOL

be like me and only update mods once every 3 years or so ;)

[IhanaMies]

I have this very issue.

My ups went from 36 to ~75 and Dyson Sphere calculation from 7.5ms to 0.5ms when I disabled this mod.
I do have 4 most dense shells under construction on the blue giant which is probably causing it.

Link to save: One Drive

PC specs:
i9-12900k, 32 gb 4800Mhz RAM, RTX 2060S

[DanielHeEGG]

Reopened with #7. I'll look into it.