Вопрос о скорости компиляции и загруженности формы

[Rcus]

Мне известно два источника открытого кода с использованием Qt: примеры (Tab Dialog Example) и kde (kmldonkey, ktorrent)

[break]

В вашем случае 100% надо разносить на разные виджеты содержимое каждого таба. И там никаких сложностей у QTabWidget есть метод

Код:

int addTab ( QWidget * page, const QString & label )

В него передается указатель на внутренний виджет. Каждая форму может быть оформлена несколькими способами - от стандартной обертки с h и cpp файлом до динамической загрузки ui. Главное получить указатель на потомка QWidget и всунуть его в таб.
У меня в программе в цикле работает такой код

Код:

		CInstr_TrainControlForm* pTC_Props_Form = new CInstr_TrainControlForm( this );
		pTC_Props_Form->show();
				
		// добавляем окошко в "ТАБы"
		ui.twTrainControls->addTab( pTC_Props_Form, QIcon(":/images/train.png"), sDescript );

У меня создаются одинаковые подтабы - внутри каждого кстати тоже QTabWidget-ы. В вашем случае они просто будут разными классами.

Как вам сказали ранее если ui файл не менялся то перекомпиляция не должна происходить долго. А если разобьете все на подвиджеты - то даже каждый раз меняя часть интерфейса перекомпиляца будет только маленькая часть - и это не займет много времени.

Хотя я даже не верю что столько времени займет компиляция вашего проекта - какой средой вы пользуетесь? Какая ОС? Сколько памяти и какой процессор? А то может у вас и Хелло Ворд не быстро собирается?

[Арктус]

2break

Спасибо за Ваш ответ. Видимо так и придется делать. Одна единственная форма с тысячами виджетов не прокатила.

По поводу машины, те времена что я указал справедливы для P4 3GHz, 1Gb оперативной.
Другие, более мощные машины (Intel Core 2 Duo + 1,5 Gb) компилят этот же проект минут за 7.(дебаг версия, релиза даже там не долждался)

Для интереса, постораюсь провернуть подобное на Builder'е, посмотрим сколько компилится там.

[break]

"P4 3GHz, 1Gb оперативной." - да машина норм. Значит действительно 1 форма с кучей компонент не решение. Но наверное ее и поддерживать через пол года в таком виде будет тяжело. Я как бы сам люблю дизайнер - мне приходилось делать имуляторы реальных устройств - и эти устройства не были идеалом дизайна - там все изначально было криво и необходимо было реализовать также. Дизайнер выручал. Но честно не представляю как вы в нем такое огромное количество виджетов расставили - для меня 100 элементов стоящих рядом - это уже кошмар - и не дай бог потребуется между 50 и 51 впихнуть еще одного QLabel, QButton и др....

[ритт]

Арктус, а можно компилябельный проектик с этой формой приложить? ну, не верится мне, что форма может компилится 7 минут...попробую у себя

[break]

Я бы тоже проверил...

[Арктус]

Потестил я тут на свою голову...

Исходный хлам: P4-3GHz, 1Gb оперативки.

Исходные данные: Создается новый проект, на форму в табы накиданы Label, ComboBox, Edit, Button. Просто накидал в дизайнере. Своего кода нет.

Builder6:
На форме:
Label: 2604
Edit: 1302
ComboBox: 1302
Button: 490
Общее количество объектов на форме: 5698
Плюс пара десятков табов
Время компиляции 3-5 секунд. (дебаг), 30 секунд (релиз)

QtCreator (тот что в комплекте Qt SDK by NOKIA 2009.03)
На форме:
Label: 1440
Edit: 720
ComboBox: 720
Button: 528
Общее количество объектов на форме: 3408
Плюс пара десятков табов
Время компиляции: 4 часа 5 минут 30 секунд (дебаг версия, релиз запускать как-то боязно)

Обе IDE установлены из коробки, никаких настроек.

Кто-нибудь может провернуть подобный тест?
Хорошо бы было Qt-проект попробовать на студии собрать. Я всеж пока склоняюсь к тому, что уши от MinGW растут. (либо есть какие-то шаманства при настройке, которые надо сделать)
В разгар компиляции, процесс отжирал себе до 800 мб оперативной памяти.

Арктус, а можно компилябельный проектик с этой формой приложить? ну, не верится мне, что форма может компилится 7 минут...попробую у себя

Я его тут в пылу борьбы того... копия только на работе. Если после вышеизложенного все еще интересно, в понедельник могу подкинуть.

[Rcus]

После пары минут компиляции сомнения как-то начали развеиваться, но gcc-4.3.3 справился за 5 минут.
Хотя конечно один взгляд на вывод uic проясняет суть дела, файл в 29KLoC это жесть
Прилагаю ui файл для теста.
Запускать не пробовал, боюсь oom

[uriel]

Сурово.
GCC 4.4.0 в релизе собрал за 3:23, а в дебаге - 0:11.
Oom, кстати, никакого нет - оно всего 6 метров кушает.

[Арктус]

Взял ui файл предложенный Rcus. Кстати, спс за него, подчерпнул кое что для себя новое, в плане работы в дизайнере.

Запихнул в проект, начал компиляцию.
Получаю такое дерево процессов:
mingw32-make.exe -> mingw32-make.exe -> cmd.exe -> g++.exe -> cc1plus.exe

Этот cc1plus.exe отработал полтора часа, и мне надоело как-то. Учитывая что там объектов больше чем у меня было, даже не хочу думать, как долго оно бы длилось. На пике активности cc1plus.exe затребовал 673 Мб.

Для интереса усек форму немного.
4 таба (900 объектов): время 240 секунд и 159 Мб памяти.
3 таба (670 объектов): время 102 секунды и 126 Мб памяти
2 таба (450 объектов): время 33 секунды и 99 Мб памяти.

Таки интересно, в чем трабл. Откуда такие бешенные времена идут.

[pastor]

Попробовал и я под виндой:

Intel Core 2 Quad Q6600 (2,40 ГГц), 8 Gb оперативки, Qt 4.5.1, MSVC 2008 + SP1

1) Debug - 2:35 мин, съело 160 метров при линковке
2) Release - подождал 5 мин и прервал сборку, т.к. стало съедать память огромными темпами (съело 4 гига оперативки).

[Rcus]

Таки интересно, в чем трабл. Откуда такие бешенные времена идут.

Думаю тут проблема в размере генерируемого класса. Я внутренностей gcc не знаю, но думаю класс размером в тысячи слов это крайне атипичное явление. Вполне может быть неоптимальное заполнение таблицы символов при трансляции, что вызывает нелинейную деградацию скорости.

И почему так быстро работает BCC+VCL понятно: там весь код инициализации виджетов находится в .dfm файле. Интересно кстати посмотреть, запустится ли пример VCL на загруженной системе: вполне может сработать ограничение на количество GDI объектов в системе

[Арктус]

Думаю тут проблема в размере генерируемого класса. Я внутренностей gcc не знаю, но думаю класс размером в тысячи слов это крайне атипичное явление. Вполне может быть неоптимальное заполнение таблицы символов при трансляции, что вызывает нелинейную деградацию скорости.

И почему так быстро работает BCC+VCL понятно: там весь код инициализации виджетов находится в .dfm файле. Интересно кстати посмотреть, запустится ли пример VCL на загруженной системе: вполне может сработать ограничение на количество GDI объектов в системе

К вопросу о BCC, тот пример на Builder6, с 5600+ объектами, dfm файл содержит почти 45 тысяч строк. Скорость обработки 5 секунд на дебаг, 30 на релиз с оптимизацией кода на скорость. Размер получающегося exe файла 1,07 Мб.
При запуске экзешник занимает всего 53 GDI Handels (если я правильно понял, о чем Вы) и 6 Мб оперативной памяти.

[SABROG]

Тоже провел тест:
GCC 4.4.0
debug - 27 сек, пиковое использование памяти 500Mb
release - 6 мин, пиковое использование памяти ~1Gb
---
С выключеной оптимизацией (-O0) release - 23 секунды.

Тачка: Intel Core 2 CPU 6400 2.13GHz, RAM 2Gb, Windows XP, консоль cmd
---
Для эксперимента решил попробовать использовать новую фичу GCC 4.4.0 - точечную оптимизацию. Открыл файл ui_untitled.h и проставил методу setupUi нулевую оптимизацию:

Код:

void setupUi(QMainWindow *MainWindowClass) __attribute__((__optimize__("O0")))

Не смотря на то, что сама программа собиралась с ключом оптимизации -O2 - программа в релизе собралась за 33 секунды.
В аттаче компилируемый пример, для тех кто еще захочет потестить.

[break]

Взял пример из предудыщего сообщения
debug - секунд 30
release - Cannot allocate memory - после 2-х минут

Intel Core 2 Duo, 4GB, Ubuntu 8.04, QtCreator 1.2