Qt и расход памяти

а разве нельзя создать кутешное приложение (консольное) не создавая экземпляр qapplication?

Ну а если интересует гуишное.
2МБ за простейшую хрень....

А зачем маленьким приложениям гуй?

pmap -d показывай

Причём здесь GUI? В Qt базовый класс это QObject. Чтобы его создать (или вообще сделать любой куте объект) надо подключить библиотеку QtCore. Напрмер в Debian'е sid библиотека libQtCore.so.4.4.3 весит 2 271 276 байт. В винде QtCore4.dll весит 2 662 912 байт (mingw/Qt 4.4.3). Именно они "отъедают" память.

>pmap -d показывай
Я так понимаю последняя строка интересует.

пустое приложение
mapped: 85740K writeable/private: 928K shared: 2072K

пару виджетов(лейбл, кнопка, слайдер, спинбокс)
mapped: 89068K writeable/private: 4236K shared: 2072K

>Причём здесь GUI? В Qt базовый класс это QObject. Чтобы его создать (или вообще сделать любой куте объект) надо подключить библиотеку QtCore. Напрмер в Debian'е sid библиотека libQtCore.so.4.4.3 весит 2 271 276 байт. В винде QtCore4.dll весит 2 662 912 байт (mingw/Qt 4.4.3). Именно они "отъедают" память.

Я не против того, что libQtCore подгружается. Мне не нравится, что создав 50 простеньких приложений, динамически слинкованых, у меня отъелось 200 МБ памяти.

Пересборка qt с оптимизацией по размеру(-Os для gcc/mingw) и отключение С++ exceptions при конфигурации Qt дадут уменьшение размера отъедаемой памяти до 1,5 мб.

Если совсем жалко памяти, то не используйте Qt,а дергайте родное api платформы и не будет расхода памяти. Есть ,в конце концов, Qt for Embedded Linux и Qt Extended.

>Если совсем жалко памяти, то не используйте Qt, а дергайте родное api платформы и не будет расхода памяти.

Жалко. Ну хрен с ним с маком и виндой. А что в линухе прикажете использовать в качестве "родного api"?

А жалко потому, что где же юникс вей? Где идея про много мелких тулз, если каждая будет на ровном месте мегабайты жрать?

Как между собой юникс и qt связаны?

> Я так понимаю последняя строка интересует.

Нет, как раз карта памяти.

Вот пустое приложение:
ftp://kawais.org.ua/incoming/qt_blank.txt
Вот с виджетами:
ftp://kawais.org.ua/incoming/qt_simple.txt

libQtCore.so - это shared object, и shared тут не спроста, очень даже не спроста.

Да и еще.. Я не пытаюсь ничего доказать или сказать что-то плохое про Qt. Я лишь хочу разобраться с вопросом.

>Мне не нравится, что создав 50 простеньких приложений, динамически слинкованых, у меня отъелось 200 МБ памяти.

донесу до тебя понятие "shared". shared - это когда один и тот же кусок памяти (код + данные только для чтения) доступен нескольким приложениям, не копируясь между ними. если написано 2мб shared, то каждая следующая прога не грузит заново либу, а юзает уже лежащее, тем самым снижая расход памяти.

0000000001ba9000     480 rw--- 0000000001ba9000 000:00000   [ anon ]
против
0000000000672000    3788 rw--- 0000000000672000 000:00000   [ anon ]

Можно предположить, что qt отхватило памяти под экранный буфер, в который рисует в оффскрине, а потом одним махом бросает в реальный фреймбуфер.

Читай, что человек пишет: writeable/private: 4236K

>донесу до тебя понятие "shared". Да знаю я что такое shared... И говорю же.. мне не либы, подгруженые мешают

>Можно предположить, что qt отхватило памяти под экранный буфер, в который рисует в оффскрине, а потом одним махом бросает в реальный фреймбуфер.
Может быть... 

И вот, что интересно. 
for(int i=0;i<50;i++){
   mainWindow *m = new mainWindow(app);
}  
И памяти расходет столько же(с точностью до погрешности), сколько одно приложение с одним окном.

> И памяти расходет столько же(с точностью до погрешности), сколько одно приложение с одним окном.

Можно в исходниках посмотреть, что там на самом деле происходит, но что-то в говне сегодня ковыряться не охота.

Не понимаю. Чего вы хотите добиться в стиле "много мелких тулз"? Много мелких гуи тулзов? Это явно не юниксвэй, а херня какая-то. Тут проще сделать всё в одном. А вот если делать консольные приложения Qt, то они явно не будет отбирать столько памяти. А делать их ессно надо не с помощью QApplication, а с QCoreApplication. Вообщем читать RTFM.

Нуну... есть с десяток прог. Каждая делает что-то одно и не зависит от других. Возможно будут все 10 использоваться вместе, возможно нет. Пихать их все в одно - маразм. И отдавать с 50МБ под это дело тоже. И жа они гуи. тут все-равно юникс_вей/не_юникс_вей, а объединять их в одно - маразм.

Млин зайка тебе же сказали
либа шареная то бишь все твои 50 прог
будут юзать один и тот-же кусок памяти с либой,
а не каждая +2 метра.
А память которая выделяеться малоком
под что-то, сделай трейс и посмотри сколько ее и зачем,
в любом случае ГУЙ ЖРЕТ ПАМЯТЬ и от этого никуда не деться.
Хочешь экономить память пиши на С под консоль, юзай глибс
и забудь про всякие жирные либы.

Удачи.

О дорогой анонимус, ты дурак или читать не умеешь?

Если второе, то читай:

>mapped: 89068K writeable/private: 4236K shared: 2072K

Если и сейчас не видишь, то 4236K... Да.. 4МБ НЕ ШЕАРД...

> Заметил, что любое приложение Qt автоматически отъедает около 2МБ

Пустое приложение на Свинг отъедает 22М и ничего :)

Скажу так. QT очень много какой статический информации тащит.

Создание просто приложения - это сложный процесс. Для начала - это очерь сообщений. А раз очередь - то это значит должна быть карта обработчиков этих сообщений. А если карта - то линка. Это раз.

Два - не забываем, что qt и С++ несколько не близкие концепции. Поэтому многие вещи из С++ qtшники дублируют, и жрут этим память хорошо. Поэтому оптимизация под размер может что-то и дать, но немного.

Да и треть. Эта очередь --- штука хиртая. На чем она точно реализована - не знаю. Ну думаю что просто основной API для реализации этого может откушать хорошо..

ЗЫ: да и забыл. Да. Под каждое окно выделяется backbuffer для отрисовки

Ну что-ж всем большое спасибо. =)

ЗЫ я вообще думал на питоне писать. Дык вместе с интерпритатором это выливается в 10МБ =))