In my previous post I compared the performance of a single QT connection with the performance of a notification mechanism based on virtual functions.
In this post I’ll demonstrate how the performance of QT signals degrade when the number of the connections grow. Briefly saying a QT signal becomes 57 times slower than a virtual function.
Below I described my experimentations and provided the full source code.
(more…)I defined a QT Object that contains an integer value and uses QT signal along with awl::Observable based on virtual functions to notify the subscribers when the value changes:
#include "Awl/Observable.h"
#include <QObject>
namespace test
{
class NotifyValueChanged
{
public:
virtual void onValueChanged() = 0;
};
class ValueObject :
public QObject,
public awl::Observable<NotifyValueChanged>
{
Q_OBJECT
public:
Q_PROPERTY(int value READ value WRITE setValue NOTIFY valueChanged)
void notifyValueChanged()
{
Notify(&NotifyValueChanged::onValueChanged);
}
signals:
void valueChanged();
I did not expect that its share of CPU usage in my app is 12.15%:
Why does it iterate over some collection? Isn’t there only one sender in a thread?
(more…)After various experimentation I was able to build QT 6.3.1 with OpenSSL for Windows with the following steps:
Extract archives with Bash:
tar -xzf ../distrib/openssl-1.1.1q.tar.gz
tar -xf ../distrib/qt-everywhere-src-6.3.1.tar.xz
Run the following commands with x64 Native Tools Command Prompt for VS 2022:
set PATH=%PATH%;C:\dev\PFiles\Strawberry\perl\bin
set PATH=%PATH%;C:\dev\PFiles\nasm-2.15.05
perl Configure VC-WIN64A
Run the following commands with x64 Native Tools Command Prompt for VS 2022:
set PATH=%PATH%;C:\dev\PFiles\Strawberry\perl\bin
set PATH=%PATH%;C:\dev\PFiles\nasm-2.15.05
set MY_INSTALL_DIR=C:/dev/libs/OpenSSL
perl Configure VC-WIN64A --prefix="%MY_INSTALL_DIR%" --openssldir="%MY_INSTALL_DIR%"
An example of how it can be configured:
set "CMAKE_ROOT=E:\PFiles\cmake-3.21.3-windows-x86_64\bin"
set "NINJA_ROOT=E:\PFiles\ninja-win"
set "JDK_ROOT=C:\Program Files\Java\jdk1.8.0_301\bin"
set "MINGW_ROOT=E:\PFiles\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin"
set "PERL_ROOT=E:\PFiles\Strawberry\perl\bin"
set PATH=C:\WINDOWS\system32;C:\WINDOWS
set PATH=%CMAKE_ROOT%;%PATH%
set PATH=%NINJA_ROOT%;%PATH%
set PATH=%JDK_ROOT%;%PATH%
set PATH=%MINGW_ROOT%;%PATH%
set PATH=%PERL_ROOT%;%PATH%
set PATH=E:\PFiles\Python35;%PATH%
rem Check if the tools are in PATH
where gcc
where mingw32-make.exe
where perl.exe
where javac.exe
where python.exe
where cmake.exe
where ninja.exe
set "ANDROID_SDK_ROOT=C:\Users\D-Ef\AppData\Local\Android\Sdk"
set "ANDROID_NDK_PATH=C:\Users\D-Ef\AppData\Local\Android\Sdk\ndk\24.0.8215888"
set "ANDROID_BUILD_TOOLS_REVISION=31.0.0"
set "ANDROID_BUILD_ABI=x86_64"
rem set "ANDROID_BUILD_ABI=x86"
rem set "ANDROID_BUILD_ABI=arm64-v8a"
rem set "ANDROID_BUILD_ABI=armeabi-v7a"
set MY_INSTALL_PATH=E:/Qt/Qt6.3.0/android.%ANDROID_BUILD_ABI%
set QT_HOST_PATH=E:/Qt/Qt6.3.0/windows
configure.bat -platform win32-msvc -xplatform android-clang -prefix %MY_INSTALL_PATH% -qt-host-path %QT_HOST_PATH% ^
-c++std c++20 -no-openssl ^
-DQT_NO_EXCEPTIONS=1 -release -force-debug-info -opensource -confirm-license ^
-android-sdk %ANDROID_SDK_ROOT% -android-ndk %ANDROID_NDK_PATH% -android-ndk-platform android-23 -android-abis %ANDROID_BUILD_ABI% ^
-skip qt3d -skip qt5compat -skip qtactiveqt -skip qtcharts -skip qtcoap -skip qtconnectivity ^
-skip qtdatavis3d -skip qtdoc -skip qtlottie -skip qtmqtt -skip qtnetworkauth -skip qtopcua ^
-skip qtserialport -skip qtpositioning -skip qtquicktimeline -skip qtquick3d -skip qtremoteobjects ^
-skip qtscxml -skip qtsensors -skip qtserialbus -skip qtvirtualkeyboard -skip qtwayland ^
-skip qtwebchannel -skip qtwebengine -skip qtwebview
Now QT doesn’t like backslashes in configure.bat parameters. Also I updated vcvarsall.bat path and added -c++std c++20: and tried static build with -static option:
CALL "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
set "CMAKE_ROOT=E:\PFiles\cmake-3.21.3-windows-x86_64\bin"
set "NINJA_ROOT=E:\PFiles\ninja-win"
set "PERL_ROOT=E:\PFiles\Strawberry\perl\bin"
set PATH=%CMAKE_ROOT%;%PATH%
set PATH=%NINJA_ROOT%;%PATH%
set PATH=%PERL_ROOT%;%PATH%
set PATH=E:\PFiles\Python35;%PATH%
rem Check if the tools are in PATH
where perl.exe
where python.exe
where cmake.exe
where ninja.exe
set "MY_INSTALL_PATH=E:\Qt\Qt6.3.0\windows"
set CL=/MP
configure.bat -prefix %MY_INSTALL_PATH% -DQT_NO_EXCEPTIONS=1 -debug-and-release -force-debug-info -platform win32-msvc -opensource -confirm-license ^
-c++std c++20 -static -I "C:/Program Files/OpenSSL/include" -L "C:/Program Files/OpenSSL/lib"
It is a long story that started here about 2 years ago. My first understanding was that it is a QT bug that was not fixed within this 2 years, of course (as a rule or usually), but a couple weeks ago I noticed that a similar crash happens on Samsung Galaxy devices:
#00 pc 000000000005fcb2 /apex/com.android.runtime/lib/bionic/libc.so (abort+166)
#00 pc 00000000000a9393 /apex/com.android.runtime/lib/bionic/libc.so (__fortify_fatal(char const*, ...)+26)
#00 pc 00000000000a8b9d /apex/com.android.runtime/lib/bionic/libc.so (HandleUsingDestroyedMutex(pthread_mutex_t*, char const*)+20)
#00 pc 00000000000a8a89 /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+132)
#00 pc 00000000000a7879 /apex/com.android.runtime/lib/bionic/libc.so (pthread_cond_wait+40)
#00 pc 000000000004de2d /system/lib/libc++.so (std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)+8)
#00 pc 000000000038a7f1 /system/lib/libhwui.so (android::uirenderer::CommonPool::workerLoop()+60)
#00 pc 000000000038a73f /system/lib/libhwui.so (void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, android::uirenderer::CommonPool::CommonPool()::$_0> >(void*)+94)
#00 pc 00000000000a8147 /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+20)
#00 pc 0000000000061467 /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30)
Found an example of overriding co_await operator and was able to implement my own version:
#include <QTimer>
#include <QMetaObject>
#include <chrono>
#include <coroutine>
//QTimer accepts only milliseconds.
class TimeAwaitable
{
public:
explicit TimeAwaitable(std::chrono::milliseconds d) : m_d(d) {}
~TimeAwaitable()
{
if (m_connection)
{
QObject::disconnect(m_connection);
}
}
bool await_ready() const noexcept
{
return m_d <= std::chrono::milliseconds(0);
}
void await_suspend(std::coroutine_handle<> h) noexcept
{
m_connection = QObject::connect(&m_timer, &QTimer::timeout,
[this, h]()
{
QObject::disconnect(m_connection);
h.resume();
});
m_timer.setSingleShot(true);
m_timer.start(m_d);
}
void await_resume() const noexcept {}
private:
std::chrono::milliseconds m_d;
QTimer m_timer;
QMetaObject::Connection m_connection;
};
inline TimeAwaitable operator co_await(std::chrono::milliseconds d) noexcept
{
return TimeAwaitable{ d };
}
For those who did not work with QT, QTimer::singleShot simply calls the lambda on the current thread after a given interval.
