Performance decay in Build 143

When running Monte Carlo or Walk-Forward Matrix simulations on version 143, there is a noticeable overall performance degradation (with memory usage continuously increasing) compared to version 142. In addition, version 143 frequently crashes with out-of-memory errors. SQX always limits memory to 8 GB, but even when increasing it, the application still crashes.

My PC is an AMD Ryzen 9 5900X with 32 GB of RAM. I tested it using GraalVM as well as Azul Java, with the same behavior.

Has anyone else noticed this issue?

I went back to using version 142, since version 143 is currently unsustainable to work with.

The new version is really disappointing. I also have the same problem. I have a powerful pc build yet it slows down considerably at the last bunch of strategies during retest with little RAM usage which is frustrating

Lorena, can you share your builder configuration and share also screenshot with CPU/Memory settings? I will test this in both versions

You can send to our email [email protected]

I think – I have the same issue.  I have 256GiG Ram free to use 248Gig and 64 CPUs. I installed into a new directory and copied across

in 142 the memory used to creep up, in 143 it feels like it maxes out quite quickly.

Yeah, it’s happening the same to me.

If I let SQx determine the RAM usage, it keeps stopping because of the 85% consumption memory, I’ll maybe go back to 142 as you are suggesting, since the IA of the AlgoWizard is completely useless for me.

I’ll try one more run of a Custom Project and I’ll let you know.

Plus I’m just running one task on 143 when I was used to have one builder and one retester going in 142 without problems.

Hi guys, I went back to 142 again, 143 was fully unstable and constantly crashing and freezing out.

Let’s see if my workflow in 142 is better.

yo probe en 143 y tuve que volver al 142. Un trabajo para que el constructor del 142 procesaba 100.000 algoritmos por hora , el 143 procesaba la mitad o la tercera parte.

Same problem here, we have wrote to Support but the same issue after some tests. we are Trying to re-install

HI, and the problem is now fixed ? have you find the solution then ?

I went back to 143 to make some tests and stayed here, I just let the garbage collector to the Java Decisions, make a 30 mins collecting garbage and reduced the ram and cores to the 1/2 of my available ones, and it’s working fine

Estou na versão 143 brasileira, e coloquei os erros em anexo, não consigo resolver isso.
Servidor dedicado da NETCUP com 20 nucleos 64GB ram e 3 TB de armazenamento. Não consigo rodar mais de 2 horas ele já trava. As vezes ele trvou até aberto sem rodar qualquer projeto ou teste.

Hi everyone,

I want to address the performance concerns raised about build 143.

There are no intentional changes to the core engine in this version, and after running internal comparisons between build 142 and 143, we found no measurable difference in engine performance under controlled conditions. That said, because StrategyQuant X is Java-based, performance can vary significantly depending on your hardware, operating system, and Java distribution — factors outside our control.

After investigating reports from affected users, I found that most issues can be resolved by following these configuration guidelines:

Java & GC:

• Do not manually trigger Garbage Collection (GC). Java manages this automatically; forcing it can actually hurt performance. Only consider manual GC if you’re experiencing out-of-memory errors.
• Use the G1 Garbage Collector when working with larger heap allocations.
• For high-end machines, GraalVM + G1GC is recommended for best performance and stability.
• Test multiple Java distributions and compare results on your specific setup. Simply download the Java distribution from official sources, unzip it, and replace the /j64 folder in your StrategyQuant installation with the downloaded version.

Data & Memory:

• Avoid storing large numbers of strategies in SQX Databanks. These are held in heap memory (RAM) at all times, consuming resources even when not in use. Store strategies externally and load them only when needed.
• The same applies to Monte Carlo and Walk-Forward simulation results — keep Databanks lean.
• Set the maximum heap memory (RAM allocated to SQX) to approximately 80% of your total RAM. This gives SQX enough memory to work with while leaving headroom for the OS and background processes.

System:

• Limit background processes while running SQX.
• Match your SQX thread count to your physical CPU core count (not logical/hyperthreaded cores).
• Beyond the recommendations above, avoid changing SQX configuration or Java flags unless you have a specific reason and understand the implications.

Following these steps resolved the majority of performance issues we’ve seen — and in most cases, the root cause was not SQX itself.

If you’re still experiencing problems after trying these steps, please reach out to us at our support email.

We’re happy to help

Best regards,

Petr
SQX Technical Support

Dear Petr,

thanks again for your support now Our 143 Ultimate Works Perfectly!!

Best regards

Interesting that in controlled tests there’s no real difference between 142 and 143, but in actual projects everything seems to depend heavily on configuration and workload. It really shows how important proper environment optimization is.