Is there any performance fixing mod?

[Gotmachine]

39 minutes ago, R-T-B said:

honestly, just use the profiler.

Well, I wouldn't recommend using the Unity profiler for general performance profiling.

The Unity profiler is mainly useful for doing targeted profiling and optimization, identifying specific issues (its deep profiling capabilities is quite useful for that), identifying sources of GC allocation pressure. It's a great tool for plugin developers, but not so much for end users.

And a major issue with it is that using it require to turn your install into a development build, which has the side effect of disabling a lot of Mono and Unity optimizations.
This not only has a significant impact on overall performance, but that impact is also very uneven depending on how much those disabled optimizations are applying to a specific code path.
I've seen some cases of code running over three times slower in a development build, typically in tight managed loops or when doing a lot of specific unity API calls.

That's the whole point of the "KSP Profiler" mod mentioned above : it can run in a normal unmodified install, is pretty straightforward to use and is inducing very minimal overhead.

Edited May 23 by Gotmachine

[JonnyOThan]

11 hours ago, Lisias said:

Did you profiled KSP with and without KSPCF as I'm doing using a controlled Test Bed with a deterministic Test Session? Did you compared the results? Can you publish them, as I did now?

Yep!  I’ll get some stuff together…Oh!  I just saw gotmachine’s post. Guess I don’t need to.

Also he may have been testing in sandbox, and there are some specific fixes in KSPCF that dramatically improve performance in career mode, and in non-stock systems, etc.

1 hour ago, Gotmachine said:

It's a great tool for plugin developers

Which is why I was surprised Lisias wasn’t using it…

Edited May 23 by JonnyOThan

[Lisias]

14 hours ago, Gotmachine said:

I won't enter a whole debate about your claims, they are made from measurements done in vague and unreliable ways, especially the part about comparing the FPS curves while manually doing a scene switch and moving the camera.

Because this is how users evaluate performance. And since it's an user asking questions, this is exactly how I answered them.

 

14 hours ago, Gotmachine said:

There are a million things that could affect the shape of those curves, and I very much doubt you're able to reproduce any of it consistently.

So you are telling me that I'm in fault with the Trueness when I said (and I quote myself):

23 hours ago, Lisias said:

@anis, I did a "quick & dirty" benchmark between an almost pristine 1.12.5 installation (Stock + DLCs + a few mods to allow checking the FPS) and tried it with and without KSPCF.

<...>

Keep in mind that this test sessions were made without too much "scientific rigor" - I didn't closed any running programs (Firefox, Thunderbird, etc), didn't rebooted the machine between tests, nothing. What I did was to first do a test run with KSPCF installed and then another one without, and vice versa - and I got similar results on the respective test sessions. What I reported above was the second batch (without KSPCF first).

Emphasis are new.

 

14 hours ago, Gotmachine said:

Anyway, having some time to loose this morning, I grabbed the show FPS mod and did a few tests on my desktop (5800X3D / 6800XT).

Thanks for clarifying it. Now, now let's try to reproduce the tests on a Potato machine, like mine and @anis?

In time, could you please publish the logs of that test run, the same way I did, so I can compare these results?

 

14 hours ago, Gotmachine said:

Also took the time to repeat your stratolauncher test on my pretty crappy laptop (that test is pointless on my desktop as it runs at 300+ FPS).

The laptop has 8GB of low speed single channel DDR4, and a Pentium silver N5030, vastly slower than the I7-3720GM in your Mac, but with a better iGPU. Overall, I'd say this is a somewhat equivalent config.
I did the tests with every graphic settings set to the minimum, and at a 720p resolution to avoid being GPU bound as much as possible, but that didn't help much, I'm still GPU bound in almost every situation.

Not exactly a good comparision, because you have a better GPU and half the memory. [edit: wrong! It's an excellent comparison, because it's showing differences between machines of the same class with slightly different configurations]

Additionally, did you used my settings.cfg? If not, you didn't reproduced my Test Session. That settings are the settings I use to play 1.12.5 on my Potato, and besides I doubt it would be the same settings @anis is using now, depending on how potato is their machine, they should consider.

 

14 hours ago, Gotmachine said:

On a side note, that mod is crap, because in itself it adds a lot of overhead (3% to 5% frame time overhead), and that overhead grow significantly with how many points are shown on its graph, heavily skewing the results.

But since it was used on both Test Sessions, the negative effects nullified themselves on the final results - we are not on a contest, this is a benchmark and it's the reason the test must be done on the same machine twice, one with and another without KSPCF.

I'm not worried about how much "real" are the numbers. The difference between the numbers on the two Test Sessions is the goal of these Tests - this is a benchmark, not a contest for the best FPS!

 

14 hours ago, Gotmachine said:

I'd say that in general, without 100% automated and deterministic testing, and without specialized CPU, GPU and memory profiling tools, trying to identify the constraints on such low end machines is an exercise in futility.

No doubt, being the reason I'm not using these tests to any other objective but to answer's @anis questions. In special, I'm putting in check the affirmation:

On 5/21/2024 at 1:30 AM, JonnyOThan said:

KSP Community Fixes is that miracle mod.

What you debunked yourself, while I was initially thinking that perhaps the problem would be my potato being too much of a potato:

14 hours ago, Gotmachine said:

Concerning KSPCF, a few remarks :

- In the specific test case you're using, there is nothing in KSPCF that can improve or degrade performance.
- Most performance related tweaks in KSPCF are a targeted fix for a specific stock inefficiency. They can make a significant difference for the specific cases they apply to, but there is no silver bullet "game changer" performance tweak.
- An important fix is getting ride of the stock (and mods) memory leaks, which is a very problematic cause of performance degradation (not to say outright crashes) over long play sessions. If you want to measure the difference KSPCF makes here, an easy way is to just repeatedly quickload the same (preferably large, 100+ parts) vessel a good 30-40 times and to check memory usage.

And, please, note what I had wrote myself:

23 hours ago, Lisias said:

From the performance on Flight Scene point of view, I'm not seeing what KSPCF could do for you - but it does some other things that may interest you, so you probably should try it and see for yourself if it will make things better for you in any other area.

IMHO I'm managing to manage the user's expectation in a somewhat better way.

You just helped me to prove this point, your test session using your potato got about ~4 FPS higher  between using KSPCF or not, what's besides being a better score than mine, can be attributed to the better GPU too, and so KSPCF would not be doing too much of a difference on mine because the GPU would be screwing any performance improvements.

Being that the reason I said to the user to give KSPCF a chance nevertheless, they need to see the results on their machine, as it's where they are going to play the game.

This dirty and quick benchmark of mine is something that they can do on its machine themself, so it's something that they can validate (or not) and then take a better decision.

The purpose of this benchmark is getting clear now?

Can you guys please understand that I'm not trying to undo KSPCF's reputation, but instead trying to answer the user in a way he could understand and see, and manage their expectations so they don't get disappointed when the miracle doesn't happens?

 

13 hours ago, R-T-B said:

I agree.  I say that as a guy who used to use the FPS-mod in a stripped down fashion (no graphs for less overhead) to get metrics, and still do sometimes, but honestly, just use the profiler.  It's one of the main benefits of Unity, and not using it is ignoring a major boon we have.

People here are not addressing the user's questioning, but turning this into a World's Columbian Exposition trying to gather attention to their stand by yelling louder.

 

11 hours ago, JonnyOThan said:

Yep!  I’ll get some stuff together…Oh!  I just saw gotmachine’s post. Guess I don’t need to.

Yes, you need. This is not a contest, we are trying to understand how KSPCF behaves on different potatoes so we can give a proper, expectation managed answer to the user.

 

11 hours ago, JonnyOThan said:

Also he may have been testing in sandbox, and there are some specific fixes in KSPCF that dramatically improve performance in career mode, and in non-stock systems, etc.

Specific fixes that are not being demonstrated on my potato, and so I can't affirm to the user KSPCF is going to be that "miracle mod" you promised.

Now, it would be a excellent idea to create some savegames with specific scenarios demonstrating where KSPCF would really help performance (because there's no doubt that it helps on other areas of the game, just to make it clear).

=== == = BRUTE FORCE POST MERGE = == ===

Just an addendum:

14 hours ago, Gotmachine said:

- An important fix is getting ride of the stock (and mods) memory leaks, which is a very problematic cause of performance degradation (not to say outright crashes) over long play sessions. If you want to measure the difference KSPCF makes here, an easy way is to just repeatedly quickload the same (preferably large, 100+ parts) vessel a good 30-40 times and to check memory usage.

This is the reason one should not use MacOS as a primary profiling tool. [edit: you should profile your weakest link, not the strongest!]

MacOS does transparent memory compression, allowing a process to overcommit way more memory than Windows, masking these performance problems caused by memory leaks.

My rig has only 16GB of RAM, but I managed to get KSP to commit over 38 GB before getting liquided enough to kill the process. Someone must tell me that there's a severe memory leak or I will just not notice it without looking specifically on the issue using vm_stat (or whatever you think you should use to locate how the memory is being overcommited).

So huge memory leaks as KSPCF aims to workaround don't have that impact on MacOS as it have on Windows, unless the leak is so severe, but so severe, that it would be happening on Update or FixedUpdate - but that would make the thing unusable on Windows before a Mac Users would even be aware of the mod existence.

Edited May 24 by Lisias
Tyops gallore!!

[JonnyOThan]

1 hour ago, Lisias said:

The gist of it is: it would take far more energy than I have. If I believed this option was possible, I would do it (because usually, this is the best option).

I mean, you took the energy to measure the fps. It’s just a different tool.  You’re not profiling your mods?

[Deddly]

Guys, can we maybe have a conversation about performance measurement and improvement without making it personal or taking offense at how other people view things? Let's cut out the personal remarks, hmm? 

I'll let you all decide how best to edit your posts to make them less confrontational. Another moderator may or may not come by later and decide to do some snipping or more. 

[R-T-B]

1 hour ago, Lisias said:

People here are not addressing the user's questioning, but turning this into a World's Columbian Exposition trying to gather attention to their stand by yelling louder.

I did not read the thread title admitedly, apologies.

Edited May 23 by R-T-B

[JonnyOThan]

Yeah I’m super curious to know *why* KSPCF is having that effect on Lisias’s machine, and the profiler will tell us.  And then if there’s some way we can make it better, we will.  I don’t have a Mac or a potato, so I can’t find out on my own.

FWIW, I’ve guided several non-developer users through getting profiler captures from their games when they were experiencing bad performance, and fixed many issues via KSPCF or filed issues on other mods for improvements thanks to those captures.  If anyone (like @anis) is interested in doing that, hit me up.

[Lisias]

6 hours ago, Gotmachine said:

What you're doing is very far from a "controlled Test Bed with a deterministic Test SessioThere are a million things that could affect the shape of those curves, and I very much doubt you're able to reproduce any of it consistently.

Well, I did. The files are on my Google Drive.

WITHOUT KSPCF:

 

WITH KSPCF:

KSPCF's stil presents some "jerkyness", but the average FPS (what really counts) didn't changed.

However... You still have a point. My second run on WITHOUT KSPCF looks slightly smoother, so it's a change - not to mention that I have a big "bump" here now. Interesting enough, it also happened on WITH more or less a the same time - so we have some determinism, this is not 100% chaotic.

Thinking about, I concluded that this is environmental. I was wondering about what could caused the bump on "WITHOUT" when I noticed the Notifications icon on the Forum's page going red on the secondary monitor, and clicked on it. And then that little bump on "WITH KSPCD" happened (the first one, after the first FSP ascension).

And so I think we have some evidence that these bumps may be related to the Garbage Collector, as other process requested memory and the O.S. granted it, shrinking a bit the physical RAM available to KSP and triggering the GC. Right now is a guess, this is where we would need a better profiling tool to graph not only the FPS, but also what GC is doing.

This also hints that what I identified as "jerkyness" on "WITH KSPCF" may be related to KSPCF being a bit more memory concerning, triggering the GC regularly - what would be a better idea than letting the HEAP to be clobbered before triggering the GC - better a slightly lower FPS all the time than regular stutterings.

Edited May 23 by Lisias
Tyops, as usulla...

[Lisias]

2 hours ago, JonnyOThan said:

I mean, you took the energy to measure the fps. It’s just a different tool.  You’re not profiling your mods?

I mean... An old Mac Potato is dirty cheap nowadays. You don't have the financial means to acquired one?

Spoiler

I strongly suggest you downgrade the OS to Mojave, as it's the latest MacOS to support 32 bits applications.

You see... I have a Windows 10 notebook, a MacPotato (well, two) and a SteamDeck to do tests - with the SteamDeck having the additional benefit of being... a Steam Deck!

You should try it. Testing andp rofiling mods only on Windows is a huge disservice to your users.

Edited May 23 by Lisias
Adding spoiler

[JonnyOThan]

1 hour ago, Lisias said:

This also hints that what I identified as "jerkyness" on "WITH KSPCF" may be related to KSPCF being a bit more memory concerning, triggering the GC regularly

It really shouldn’t be.  And after several scene switches the difference should be night and day (in favor of KSPCF).  And you could always connect the profiler and get evidence for those theories rather than speculating.

After the last round of memory leak fixes in KSPCF I was able to keep KSP running on my TPKSP stream for over 100 hours.  That’s a heavily modded install under fairly constant use.  Previously it would hit over 100gb and crash after 10-20 hours.

28 minutes ago, Lisias said:

Testing andp rofiling mods only on Windows is a huge disservice to your users.

I’d dispute that, but you’re also not profiling *at all*.  Measuring FPS isn’t profiling.

[Lisias]

1 hour ago, JonnyOThan said:

I’d dispute that, but you’re also not profiling *at all*.  Measuring FPS isn’t profiling.

And I never claimed I was. I was answering to the user, not to you. What I was doing is a Benchmark.

Really, could you please put your ego aside stand down a bit? How about opening a new thread and avoid derailing this one?

Edited May 23 by Lisias
(sigh)

[anis]

When I tried KSPCF on my machine for the first time, I noticed some improvements in the loading time and the number of FPS during flights on planets and moons with atmospheres. So, I would agree that this mod enhances performance.

I mean, how can a mod that fixes bugs and optimizes the game, while applying patches, make the performance worse ? Maybe this can happen in some particular cases, but in most cases, it's absolutely worth it to install it !

I agree with @Gotmachine

[Lisias]

3 hours ago, anis said:

I mean, how can a mod that fixes bugs and optimizes the game, while applying patches, make the performance worse ?

Well, since you asked it... When you have a large codebase, having patches jumping between a far address and back will screw the L0 and L1 caches of the CPU. Every time the cache have a miss, it needs to reach the main RAM (some orders of magnitude slower) to fetch the instructions (thanks Turing there're separated caches for data and instructions nowadays), and this makes the CPU halt for some cycles waiting for the data.

The bigger the original codebase, far are being stored the patches compared with the code being patched, and more cache misses you will have.

The Harmony's site have a nice explanatory graph about the anatomy of a patch:

See? The original code will be on a basket of bytes glued together by the compiler, and the Assembly Loader will load that basket on memory after doing some more gluing (link edition). Then Harmony goes there and switch the address of some methods to pinpoint another address, that will hardly be near the original code - we call this a "far jump".

A code that originally was a loop making near calls may perform drastically different if one switch the address to a far call, depending of how much L0 and L1 cache the CPU have to play with.

But KSP runs on a virtualmachine called CLR, and this thing when "transpilling" CIL (the bytecode in which C# is compiled into) into x86's machine code (the thing the CPU really understands) does some optimizations that may influence the problem for the better (or for the worst - this is where some profiling would help, but not on the high level as being advocated here).

On some virtual machines (and now I don't really know if Mono does that), having memory to spare means that the vm can transpile the bytecode code into different x86 "versions", each one optimized to one circumstance (at least the JVM does that), and this would allow the code to use the best possible "version" on a given time. Again, I do not know Mono enough to know if it does that - but if it does, patching the code may mask the caller in a way that would make the transpiler take an less optimal decision, again influencing performance.

There is another possible explanation for things happening this way on my rig: not only my i7-3610QM processor have "only" 6MB of Cache for the 8 Threads (4 Cores) that are heavily disputed by everything and the kitchen's sink on the machine, but some years ago Apple royally screwed up performance on this machine when they mitigated the Meltdown and Spectre security flaws on Intels with hyperthreads (like my i7-3610QM). You will find me complaining about on this post (and on this one, and this another one - yeah, this bit my SAS badly).

This mitigation is applied on the Firmware that does the hardware initialization, and so AFAIK it's impossible to deactivate it, and so MacOS machines using affected processors will behave differently than any other rig using the same processor but that is not being mitigated (Linux machines have the option to turn it on or off!!).

This may be the explanation for the weird behaviour of KSPCF on my MacMini 6.2. And since I didn't knew (as I still don't) if your rig have or not an affected CPU (as you only said it's a potato, and not exactly what flavor of potato), there was a reasonable chance of you having an CPU that is affected like mine, and that a similar mitigation could be in effect for you too. Or not!

And this is also why (only) profiling this machine will not help. You need to benchmark it with similar rigs where the Meltdown and Spectre are not mitigated in order to rule out the CPU from the equation.

And it's also the reason I said to go on and try KSPCF the same - worst case scenario, you would have the same performance as me, but would still have the other features that could help you with.

=== == = POST EDIT = == ===

For the sake of curiosity, I noted a reduction of 30 seconds on my tests from the 23th (today),

without:
[LOG 13:54:12.325] [ModuleManager] INFO: Total loading Time = 234.368s.

with:
[LOG 13:31:02.376] [ModuleManager] INFO: Total loading Time = 203.560s.

Or about 13% better loading times. It's something, but not exactly a miracle. 3.9 min vs 3.39 min.

The 22th numbers are completely screwed... The rig with KSPCF took about 900s to load, while the rig without took 218 (even faster than today). This is completely off, had I noticed it before I would had discarded the Test Run and made another - Kraken knows what MacOS was doing at that time under the bonnet...

 

Edited May 24 by Lisias
Tyops, as usulla...

[Gotmachine]

Well, since we have decided to completely derail this thread...

It's true that patching a method cause it to go trough a dynamic stub, which does induce an additional overhead. Not so much because of cache locality (that just isn't a relevant factor here), but simply because the dispatching is a bit less efficient.
Somewhat fortunately depending on how you look at it, the Mono JIT used in Unity is quite outdated and isn't very smart and nor efficient to begin with, so that overhead isn't actually as significant as it would be in modern CoreCLR.
Also, as you noted, in the case of prefixes/postfixes, an additional method call is inserted, but this isn't the case with a transpiler.

We are well aware of those caveats, which is why we are careful not to patch hot path methods unless our replacements are optimizations that would in any case dwarf that overhead (a good example is the IMGUIOptimization fix).
There are some cases where we decide that fixing a bug is worth a bit of extra overhead, but overall, we are patching very few methods that are called every frame.
I have a hard time believing that could be measurable at the framerate level, but I could have missed something, and indeed, maybe there are platform specific shenanigans involved, as MacOS is notoriously badly supported by... well... everything that doesn't come from Apple.

Edited May 24 by Gotmachine

[anis]

9 hours ago, Lisias said:

Well, since you asked it... When you have a large codebase, having patches jumping between a far address and back will screw the L0 and L1 caches of the CPU. Every time the cache have a miss, it needs to reach the main RAM (some orders of magnitude slower) to fetch the instructions (thanks Turing there're separated caches for data and instructions nowadays), and this makes the CPU halt for some cycles waiting for the data.

The bigger the original codebase, far are being stored the patches compared with the code being patched, and more cache misses you will have.

The Harmony's site have a nice explanatory graph about the anatomy of a patch:

See? The original code will be on a basket of bytes glued together by the compiler, and the Assembly Loader will load that basket on memory after doing some more gluing (link edition). Then Harmony goes there and switch the address of some methods to pinpoint another address, that will hardly be near the original code - we call this a "far jump".

A code that originally was a loop making near calls may perform drastically different if one switch the address to a far call, depending of how much L0 and L1 cache the CPU have to play with.

But KSP runs on a virtualmachine called CLR, and this thing when "transpilling" CIL (the bytecode in which C# is compiled into) into x86's machine code (the thing the CPU really understands) does some optimizations that may influence the problem for the better (or for the worst - this is where some profiling would help, but not on the high level as being advocated here).

On some virtual machines (and now I don't really know if Mono does that), having memory to spare means that the vm can transpile the bytecode code into different x86 "versions", each one optimized to one circumstance (at least the JVM does that), and this would allow the code to use the best possible "version" on a given time. Again, I do not know Mono enough to know if it does that - but if it does, patching the code may mask the caller in a way that would make the transpiler take an less optimal decision, again influencing performance.

There is another possible explanation for things happening this way on my rig: not only my i7-3610QM processor have "only" 6MB of Cache for the 8 Threads (4 Cores) that are heavily disputed by everything and the kitchen's sink on the machine, but some years ago Apple royally screwed up performance on this machine when they mitigated the Meltdown and Spectre security flaws on Intels with hyperthreads (like my i7-3610QM). You will find me complaining about on this post (and on this one, and this another one - yeah, this bit my SAS badly).

This mitigation is applied on the Firmware that does the hardware initialization, and so AFAIK it's impossible to deactivate it, and so MacOS machines using affected processors will behave differently than any other rig using the same processor but that is not being mitigated (Linux machines have the option to turn it on or off!!).

This may be the explanation for the weird behaviour of KSPCF on my MacMini 6.2. And since I didn't knew (as I still don't) if your rig have or not an affected CPU (as you only said it's a potato, and not exactly what flavor of potato), there was a reasonable chance of you having an CPU that is affected like mine, and that a similar mitigation could be in effect for you too. Or not!

And this is also why (only) profiling this machine will not help. You need to benchmark it with similar rigs where the Meltdown and Spectre are not mitigated in order to rule out the CPU from the equation.

And it's also the reason I said to go on and try KSPCF the same - worst case scenario, you would have the same performance as me, but would still have the other features that could help you with.

=== == = POST EDIT = == ===

For the sake of curiosity, I noted a reduction of 30 seconds on my tests from the 23th (today),

without:
[LOG 13:54:12.325] [ModuleManager] INFO: Total loading Time = 234.368s.

with:
[LOG 13:31:02.376] [ModuleManager] INFO: Total loading Time = 203.560s.

Or about 13% better loading times. It's something, but not exactly a miracle. 3.9 min vs 3.39 min.

The 22th numbers are completely screwed... The rig with KSPCF took about 900s to load, while the rig without took 218 (even faster than today). This is completely off, had I noticed it before I would had discarded the Test Run and made another - Kraken knows what MacOS was doing at that time under the bonnet...

 

Thanks for these (very detailed) explanations !

[JonnyOThan]

7 hours ago, anis said:

Thanks for these (very detailed) explanations !

At the actual code instruction level they’re probably not too relevant - see gotmachine’s post above.  But memory caches are incredibly important for games like KSP which are pulling data from many different locations in memory (party due to how they’re programmed, partly because of using mono and unity).  Processors with huge caches like the “x3d” line from AMD have very significant performance boosts in KSP.

Unity has some newer systems to pack data closer together but KSP was built before those existed so it doesn’t use them.

[Lisias]

1 hour ago, JonnyOThan said:

At the actual code instruction level they’re probably not too relevant

I think they are.

If you are talking about machine code, two consecutive jmps will, well, take twice the time of a single jmp. Worst case scenario, a patch is a chained sequence of jmps, 4 to be more precise (the original one replaced, the prefix, the patch, the postfix). Perhaps 3, if the prefix and postfix are used as decorations for the patch, instead of of the patch being a call in the middle of the two other calls.

For anyone else not understanding, in ASM it would be something like:

METHOD_BEING_REPLACED:
	<some boiler plate>
    CALL METHOD_BEING_REPLACED_PREFIX
    CALL METHOD_BEING_REPLACED_BODY
    JMP METHOD_BEING_REPLACED_POSTFIX ; Optimization, using the POSTFIX RTN to return to the caller

      

Or perhaps:

METHOD_BEING_REPLACED:
	<some boiler plate>
    CALL METHOD_BEING_REPLACED_PREFIX
    <the method being replaced body>
    JMP METHOD_BEING_REPLACED_POSTFIX ; Optimization, using the POSTFIX RTN to return to the caller

On the best case, we have 3 extra JMPs:

• the CALL to prefix
• the respective RETURN,
• the JMP to the POSTFIX
  • The return on the POSTFIX doesn't counts, as the original method would had used one the same

So a patch would spend 4 jmps to make the same job of the original 2. Or twice the time.

And I need to remember that JMPs screws the CPU's pipelines. And that consecutive JMPs screws the CPU's pipelines consecutively.

Obviously, this on the x86 machine code level. Kraken knows what the CLR is doing with the CIL code.

So perhaps we would just need a better clarification about what's "actual code instruction"?

[JonnyOThan]

3 hours ago, Lisias said:

Obviously, this on the x86 machine code level. Kraken knows what the CLR is doing with the CIL code.

Right. Which makes everything you said irrelevant for KSP.

[Lisias]

1 hour ago, JonnyOThan said:

Right. Which makes everything you said irrelevant for KSP.

But not for the original questioning from @anis!

And, well, not knowing if it's relevant is not exactly the same knowing it's irrelevant - we can research and discuss about the mono 3.5 available optimizations and then be sure about what's relevant or not, but I think this should be done on another thread - unless @aniswants to know about, making it on topic to this one.

[Spikemaster]

On 5/23/2024 at 10:37 PM, JonnyOThan said:

 If anyone is interested in doing that, hit me up.

Teach me, sensei

 

[anis]

10 hours ago, Lisias said:

But not for the original questioning from @anis!

And, well, not knowing if it's relevant is not exactly the same knowing it's irrelevant - we can research and discuss about the mono 3.5 available optimizations and then be sure about what's relevant or not, but I think this should be done on another thread - unless @aniswants to know about, making it on topic to this one.

Thanks for your very detailed explanations about whether or not KSPCF and other mods are affecting performance. But... um... I'm not a geek or a developper ! I just want to ask if there are any mods that, in some way, improve performance or fix the game  

Edited May 25 by anis