Stage 4, day 31:
It took me a day to understand why my GUI client works perfectly well initially and end up simply freezing after few hours.
It is the classical sinkhole being smaller than the faucet throughput. Even if the sinkhole is only just a tiny bit smaller than the faucet throughput, it is only a matter of time before the bath spills.
I'm a bit unhappy about Qt framework. The CLI version is taking 5% CPU. The GUI is taking 40% at start up and slowly ramp up above 100% where it stops being real-time.
So the bottleneck is the framework. Actually, to be fair, it is either the framework or the actual GUI work.
I did make 2 optimizations in an attempt to squeeze enough performance to get back the app to be real-time. One optimization is how memory is allocated for the updates (over 1,000,000/hour of them are received) and the server code will benefit from that improvement.
Despite all that, the performance issue isn't resolved. I'm stuck. Qt don't allow to do GUI work with multiple threads.
I have a bigger box laying around somewhere that could do it but I haven't use it for so long that I'm not even sure that I can just upgrade the software on it. I might need to reinstall the whole thing from scratch. I could do that I guess. I'll seriously consider that option.
The last resort option would be to create a slowpc option. Instead of collecting data on every pairs available and keeping it for 24h and make it instantly available by a single click, I could collect the data on a needed basis. That is if you only collect data for the displayed pairs. That mean that if you open an additional pair, you wouldn't have access to its past data instantly.
Not being able to do multithreaded GUI is a serious Qt framework limitation...
It starts to get hairy again. I better stop thinking about that and just replace my PC with a faster one...
It took me a day to understand why my GUI client works perfectly well initially and end up simply freezing after few hours.
It is the classical sinkhole being smaller than the faucet throughput. Even if the sinkhole is only just a tiny bit smaller than the faucet throughput, it is only a matter of time before the bath spills.
I'm a bit unhappy about Qt framework. The CLI version is taking 5% CPU. The GUI is taking 40% at start up and slowly ramp up above 100% where it stops being real-time.
So the bottleneck is the framework. Actually, to be fair, it is either the framework or the actual GUI work.
I did make 2 optimizations in an attempt to squeeze enough performance to get back the app to be real-time. One optimization is how memory is allocated for the updates (over 1,000,000/hour of them are received) and the server code will benefit from that improvement.
Despite all that, the performance issue isn't resolved. I'm stuck. Qt don't allow to do GUI work with multiple threads.
I have a bigger box laying around somewhere that could do it but I haven't use it for so long that I'm not even sure that I can just upgrade the software on it. I might need to reinstall the whole thing from scratch. I could do that I guess. I'll seriously consider that option.
The last resort option would be to create a slowpc option. Instead of collecting data on every pairs available and keeping it for 24h and make it instantly available by a single click, I could collect the data on a needed basis. That is if you only collect data for the displayed pairs. That mean that if you open an additional pair, you wouldn't have access to its past data instantly.
Not being able to do multithreaded GUI is a serious Qt framework limitation...
It starts to get hairy again. I better stop thinking about that and just replace my PC with a faster one...
