You are not logged in. Please login or register.
QElectroTech → EN : Help, suggestions, discussions, ... → SW freezing
I almost always get SW freeze during my work. The commands keep freezing for a few seconds (10/15 sec) with every action (move, copy and paste, drag and drop, looking for library elements).
I'm using QElectrotech on a Win10, CPU 3.2GHz, RAM 12Gb
Thanks,
Rocco
What your version?
Like :
ram.png 80.97 kb, 225 downloads since 2020-07-24
Under Windows QET is very slow and sometimes freeze, if you are lucky to try under Linux you will find that the program is very fast and smooth.
Joshua try to improve this.
https://qelectrotech.org/forum/viewtopi … 498#p12498
For my part I'm trying to see what I can improve with the Windows packaging MXE cross compiler.
https://forum.qt.io/topic/78300/mingw-vs-msvc/5
https://retifrav.github.io/blog/2018/02 … tatically/
https://www.opencascade.com/content/mingw-w64-vs-msvc
Thanks for your reply, but unfortunately I have only WinOS at work.
Please try https://download.qelectrotech.org/qet/b … 0-07-24-1/
i686-w64-mingw32.static.posix.sjlj for 32 bits package.
x86_64-w64-mingw32.static.posix.seh for 64 bits package.
https://www.opencascade.com/content/mingw-w64-vs-msvc
To compare performance, I have run all OCCT tests in sequential (single process) mode. The results are as follows:
Compiler | Build time | DLL size | All tests run time | CPU diff, % |
----------------------------------------------------------------
MSVC 2010 | 29 min | 63348 Kb | 6 h 04 min | 0 |
MSVC 2017 | 30 min | 62021 Kb | 5 h 55 min | -2% |
Mingw-w64 SEH | 30 min | 61716 Kb | 6 h 07 min | +1% |
Mingw-w64 SJLJ | 35 min | 78516 Kb | 7 h 42 min | +38% |
I removed this packages, checked 64 bits package x86_64-w64-mingw32.static.posix.seh not stable and too fragile and often crashes...
Solution for windows :
Make an install folder like readytouse for the QET files
copy the sans serif ttf files from linux to the QET folder :The elements using the sans serif files
For olders computer : Dont'use AppData or Programm Data in Windows
But think like a computer in the 1980' or 1990' : XT runs under 4,77 MHz and 20MB harddisk : DOS System
Now in 2020 ....
Bad news : Load the elements very slow and freeze the screen = the installing versions 32 bit and 64bit
Good news : load the elements faster without freezing screen = readytouse version 9624 win32
PC laptop from 2009 (bios 31/07/2009)
QElectroTech V 0.80-DEV+9cdc023f3d79751d3
Compilation : GCC 9.3.0
Built with Qt 5.15.0 - Date : Jul 26 2020 : 16:33:32
Run with Qt 5.15.0 using 2 thread(s)
OS : winnt - x86_64 - Version : Windows 10
*** Qt screens ***
( 1 : 1680 x 1050 ) = 16:10 screen
Have some text removed after Windows 10
Erik
you can give this a try?
https://download.qelectrotech.org/qet/b … 0-08-07-1/
Test writeToFile on a other Thread
to improve this for windows performance
@De-Backer
It's still the same problem.
The problem is that CD CPUs go to 100%, wait there for a while, and then go down to a lower %.
They search for something that is not there.
After analysis I found the following:
Have also examined the exe file and the problem is that many dll's are missing.
Erik
@De-Backer
It's still the same problem.
The problem is that CD CPUs go to 100%, wait there for a while, and then go down to a lower %.
They search for something that is not there.After analysis I found the following:
Have also examined the exe file and the problem is that many dll's are missing.Erik
No, I compile MXE Qt cross-env in static mode for Windows packages, libs, etc, are include on the .exe binary.
But if you try to compile it in shared mode and see better performances, I would be very interested.
@Erik : this book is perfect if you have time and knowledge and want profiling QET to find bottlenecks under Windows :
Hands-On High Performance Programming with Qt 5: Build cross-platform applications using concurrency, parallel programming, and memory management
https://docs.microsoft.com/en-us/sysint … nals-suite
https://github.com/VerySleepy/verysleepy
http://www.dependencywalker.com/
https://github.com/lucasg/Dependencies
https://www.raymond.cc/blog/check-what- … -software/
No, I compile MXE Qt cross-env in static mode for Windows packages, libs, etc, .
I didn't know you can do that, given the license of qt. O_O
I didn't know you can do that, given the license of qt. O_O
Only for Windows, because cross-compil in shared mode is a pain..
https://github.com/mxe/mxe/issues/2441
https://stackoverflow.com/questions/296 … nux-fedora
https://github.com/saidinesh5/mxedeployqt
https://valdyas.org/fading/hacking/cros … using-mxe/
But building on Windows will always be slower, because of the slow terminal and the slow file system, and we know that the Windows releases of Gimp and LibreOffice are actually built on Linux. Cross-compiled for Windows. If complex projects like those can manage, we should be able to manage too.
https://invent.kde.org/graphics/digikam … undles/mxe
If someone has the knowledge and wants to take charge of finding a solution...
https://www.appveyor.com/
https://invent.kde.org/rolisteam/rolist … pveyor.yml
https://docs.travis-ci.com/user/reference/windows/
https://circleci.com/build-environments/windows/
scorpio810 wrote:No, I compile MXE Qt cross-env in static mode for Windows packages, libs, etc, .
I didn't know you can do that, given the license of qt. O_O
Another benefit of using static libraries is execution speed at run-time. Because the it’s object code (binary) is already included in the executable file, multiple calls to functions can be handled much more quickly than a dynamic library’s code, which needs to be called from files outside of the executable.
Static vs. Dynamic linking
A lot of CPU and memory is used by the ELF linking process. You can make significant savings by using a static build of your application suite. This means that rather than having a dynamic library (libqte.so) and a collection of executables which link dynamically to that library, you build all the applications into a single executable and statically link that with a static library (libqt.a). This improves start-up time, and reduces memory usage, at the expense of flexibility (to add a new application, you must recompile the single executable) and robustness (if one application has a bug, it might harm other applications). If you need to install end-user applications, this may not be an option, but if you are building a single application suite for a device with limited CPU power and memory, this option could be very beneficial.The downside of using a dynamic library is that a program is much more susceptible to breaking. If a dynamic library for example becomes corrupt, the executable file may no longer work. A static library, however, is untouchable because it lives inside the executable file.
https://stackoverflow.com/questions/466 … executable
QElectroTech → EN : Help, suggestions, discussions, ... → SW freezing
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.031 seconds (37% PHP - 63% DB) with 12 queries