Немного про нормализацию сигнатур. Мое внимание привлекло требование о необходимости нормализовывать все сигнатуры прежде чем использовать connect при изменении исходников Qt.

Нормализация представляет собой парсинг строки, уменьшение её длинны путем удаления лишних пробельных символов. Перестановка ключевых слов для оптимизации поиска нужного сигнала или слота у QObject'a. Подобный разбор происходит каждый раз, когда мы используем connect. Макросы SIGNAL() и SLOT() не дают нам нормализованную строку, они нам дают просто строку типа:

2mysignal(QString, QString)

После нормализации (QObject::normalizeSignature()) видно, что один пробел пропал:

2mysignal(QString,QString)

И т.п. В составе Qt появилась утилита /util/normalize, она пробегается по исходникам и заменяет макросы SIGNAL()/SLOT() на нормализованные сигнатуры, что сказывается на скорости соединения сигналов и слотов. Вероятно, в программах, где идет постоянное соединение/разъединение это помогло бы немного выйграть в скорости.

P.S.: однако мне не понятно, почему тролли не изменили moc компилятор таким образом, чтобы это делалось всегда на автомате.

Сообщение отредактировал SABROG - 20.6.2009, 16:59

Пользователи Qt, которые собирают свои приложения с помощью компилятора gcc наверняка замечали, что при компиляции их приложений используется ключ оптимизации -O2. В первую очередь это связано с тем, что сама библиотека Qt собранная с ключем оптимизации -O3 ведет себя не стабильно. Однако никто вам не запрещает иметь библиотеку Qt собранную с оптимизацией -O2, а вашу программу с оптимизацией -O3 или любой другой. Однако ключи компилятора прописаны в одном из spec файлов. К тому же не удобно каждый раз лезть в исходники Qt и что-то там менять глобально для всех приложений. Я нашел несколько иной выход, это замена ключей компилятора на свои прямо в .pro файле:

#OPTIMIZE += 0 #no optimization
#OPTIMIZE += 1 #code size, execution time
#OPTIMIZE += 2 #code size, exectuion time, performance of generated code
#OPTIMIZE += 3 #as 2 and some more
#OPTIMIZE += s #only size code optimization
OPTIMIZE += 3

CONFIG(release, debug|release){
    !isEmpty(OPTIMIZE) {
        *-g++*{
        OPT += -O
        QMAKE_CFLAGS_RELEASE ~= s,-O.,$$join(OPT,,, $${OPTIMIZE}),
        QMAKE_CXXFLAGS_RELEASE ~= s,-O.,$$join(OPT,,, $${OPTIMIZE}),
        QMAKE_OBJECTIVE_CFLAGS_RELEASE ~= s,-O.,$$join(OPT,,, $${OPTIMIZE}),
        message(Selected optimization: $${QMAKE_CFLAGS_RELEASE})
        }
    }
}

Таким образом наша программа может быть собрана с максимальной оптимизацией, нужно лишь изменить значение переменной OPTIMIZE. К тому же это может быть полезным на этапе проектирования приложения. В больших проектах release сборка может собираться десятками минут. Конечно можно собирать только debug, но случаи бывают разными. Поэтому, чтобы уменьшить время компиляции релизных сборок можно отключить для них оптимизацию совсем (OPTIMIZE += 0). Когда, по мнению автора, программа будет готова к выпуску в свет - оптимизацию можно включить обратно. И конечно никто вам не запрещает на свой страх использовать тонкую настройку под разные платформы:

OPTIMIZE += 3 -mtune=core2 -march=core2 -mmmx -msse -msse2 -msse3 -msse4 -mfpmath=sse

-O3 на самом деле не макисальная, а альтернативная оптимизация, и может существенно проигрывать -O2, это и в руководстве по GCC написано и по моей практике так.

Есть ещё -Os - оптимизация по размеру, жмёт основательно, я в контроллерах такую использую.

0x - полная автоматизация. Ее ведь тоже можно использовать?

такого ключа в GCC нет.
Их всего вот: -O, -O0, -O1 -O2, -O3, -Os.

оптимизация

Опечатка!

Я думал, ключи gcc и studio совпадают. Значит, ошибался....

Не такая уж и опечатка, у человека правильно мозги повернуты
автоматизация в некоторых случаях дает оптимизацю

Спасибо, конечно. Но в данном, конкретном случае эти ключики могут дать только оптимизацию! Сомневаюсь, что они могут повысить автоматизированность системы! Потому это действительно была опечатка!

__fastcall в стиле Qt. В Delphi и MSVC есть аттрибут для функций __fastcall, который позволяет вызывать функции быстрее, т.к. при передаче параметров используются регистры eax, edx и ecx. К сожалению в связи с этим есть некоторые ограничения. Параметров может быть 3 и все они должны иметь целочисленный тип (4 байта). Например:

QString QT_FASTCALL MyClass::myFunc(int par1, ushort par2, uint *par3);

Чтобы использовать макрос QT_FASTCALL нужно подключить заголовок:

#include <QtCore/QtGlobal>

Само объявление макроса выглядит так:

#if defined(__i386__) || defined(_WIN32) || defined(_WIN32_WCE)
#  if defined(Q_CC_GNU)
#if !defined(Q_CC_INTEL) && ((100*(__GNUC__ - 0) + 10*(__GNUC_MINOR__ - 0) + __GNUC_PATCHLEVEL__) >= 332)
#    define QT_FASTCALL __attribute__((regparm(3)))
#else
#    define QT_FASTCALL
#endif
#  elif defined(Q_CC_MSVC) && (_MSC_VER > 1300 || defined(Q_CC_INTEL))
#    define QT_FASTCALL __fastcall
#  else
#     define QT_FASTCALL
#  endif
#else
#  define QT_FASTCALL
#endif

Сообщение отредактировал SABROG - 6.7.2009, 14:53

QListView при инициализации считывает все строки для определения размеров.
На больших наборах данных это очень существенные затраты времени.

Чтобы этого не происходило достаточно воспользоваться setGridSize().

Правда у меня осталась другая проблема - предельное количество строк,
которое может отобразить QlistVIew - 134217724
Это огранечиние класса QVector. При этом объем, занимаемый приложением в памяти 520Mb.

Получил на форуме прикольный номер пользователя - килобайт