Обыскал весь интернет, такое ощущение что эта проблема вообще никого не волнует, а заключается она в следующем. Gui написанный с использованием qt жрет немерено памяти. То что это следствие дефолтной начиная с 4й версии двойной буфферизации это понятно. ТО что в qt ничего не мерцает это очень хорошо и приятно, но что делать с таким громадным расходом памяти. Ладно, если пустой проект с одним окошком отъедает ~8 метров памяти, но если таких окошек 10, это уже почти что сотня метров!!! Объясните, пожалуйста, как пишутся профессиональные приложения на QT при таком расходе памяти.
21.01.10 02:10: Перенесено модератором из 'C/C++. Прикладные вопросы' — Кодт
Здравствуйте, Аноним, Вы писали:
А>Ладно, если пустой проект с одним окошком отъедает ~8 метров памяти, но если таких окошек 10, это уже почти что сотня метров!!!
Думаешь, раз пустой проект с одним окном требует 8 метров, то пустой проект с 10 окнами будет требовать 80?
Re[2]: [qt] рсход памяти
От:
Аноним
Дата:
15.11.09 14:35
Оценка:
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, Аноним, Вы писали:
А>>Ладно, если пустой проект с одним окошком отъедает ~8 метров памяти, но если таких окошек 10, это уже почти что сотня метров!!!
LS>Думаешь, раз пустой проект с одним окном требует 8 метров, то пустой проект с 10 окнами будет требовать 80?
В том то и дело что я проверял: ~80 метров. Вы наверное думаете что qt подгружает свои библиотеки при запуске программы, а потом каждый виджет использует все это добро, выделяя память только для своих собственных нужд. На самом деле так и есть. Вот только есть еще такая штука как двойная буфферизация, о которой писал выше. Что бы не было мерцаний при перерисовке виджета, qt рисует все во внутреннем буфере, а это 1280*1024*4=5 242 880 как минимум для каждого полноэкранного виджета. Получается очень неприятная ситуация, когда с помощью qt очень легко и просто создавать приложения типа примеров из дистрибутива qt, а если нужно что то более серьезное то получается какой то монстр с расходом памяти 100 метров на несколько окошек.
Re[3]: [qt] рсход памяти
От:
Аноним
Дата:
15.11.09 15:26
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LuciferSaratov, Вы писали:
LS>>Здравствуйте, Аноним, Вы писали:
А>>>Ладно, если пустой проект с одним окошком отъедает ~8 метров памяти, но если таких окошек 10, это уже почти что сотня метров!!!
LS>>Думаешь, раз пустой проект с одним окном требует 8 метров, то пустой проект с 10 окнами будет требовать 80? А>В том то и дело что я проверял: ~80 метров. Вы наверное думаете что qt подгружает свои библиотеки при запуске программы, а потом каждый виджет использует все это добро, выделяя память только для своих собственных нужд. На самом деле так и есть. Вот только есть еще такая штука как двойная буфферизация, о которой писал выше. Что бы не было мерцаний при перерисовке виджета, qt рисует все во внутреннем буфере, а это 1280*1024*4=5 242 880 как минимум для каждого полноэкранного виджета. Получается очень неприятная ситуация, когда с помощью qt очень легко и просто создавать приложения типа примеров из дистрибутива qt, а если нужно что то более серьезное то получается какой то монстр с расходом памяти 100 метров на несколько окошек.
код в студию.
Re[3]: [qt] рсход памяти
От:
Аноним
Дата:
15.11.09 15:48
Оценка:
Здравствуйте, Аноним, Вы писали:
LS>>Думаешь, раз пустой проект с одним окном требует 8 метров, то пустой проект с 10 окнами будет требовать 80? А>В том то и дело что я проверял: ~80 метров.
Фиг знает что ты проверял.
Без когда ты можешь утверждать все что угодно.
Все равно никто не проверит.
Но вот мой опыт твое утверждение не подтверждает.
Re[4]: [qt] рсход памяти
От:
Аноним
Дата:
15.11.09 18:07
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>В том то и дело что я проверял: ~80 метров.
А>Фиг знает что ты проверял. А>Без когда ты можешь утверждать все что угодно. А>Все равно никто не проверит.
А>Но вот мой опыт твое утверждение не подтверждает.
Используемый объем памяти:
Если конец цикла = 0 (создается только QMainWindow) ~11 мб,
Если конец цикла = 1 ~16мб
Если конец цикла = 10 ~58 мб.
(Все компилировал в релизе)
По-моему очевиден прирост на каждое полноэкранное диалоговое окно по 5 мб, что подтверждает вышеприведенную формулу.
Хорошо, пример слишком прост и ничего общего с реальны приложением не имеет.
Тогда попробуйте открыть browser из демок.
Далее History/show all history (+2мб)
Растянуть окно на весь экран (еще +4 мб)
А теперь закройте окно и объем используемой памяти не изменится!!!!
Если повторять эту последовательность несколько раз можно легко довести разход памяти до 100
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, Аноним, Вы писали: А>>Хорошо без проблем, простейший пример T>блин, действительно есть такая проблема.... T>а чего делать?
В смысле чего делать то понятно: http://qtdocs.narod.ru/4.1.0/doc/html/qt4-intro.html Сообщения Рисования
Qt 4 поддерживает двойную буферизацию поддерживаемую всеми платформами.
Данный режим может быть отменен с помощью вызова
Ytz>Любой юзабилист скажет, что профессиональные приложения не используют одновременно по 10 окон.
Особенно -- на весь экран.
Нам хватает одного "полноэкранного", чтобы работать с кучей документов через закладки.
Re[7]: [qt] рсход памяти
От:
Аноним
Дата:
16.11.09 11:42
Оценка:
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, trdm, Вы писали:
T>>Здравствуйте, Аноним, Вы писали: А>>>Хорошо без проблем, простейший пример T>>блин, действительно есть такая проблема.... T>>а чего делать? T>В смысле чего делать то понятно: T>http://qtdocs.narod.ru/4.1.0/doc/html/qt4-intro.html T>Сообщения Рисования T>Qt 4 поддерживает двойную буферизацию поддерживаемую всеми платформами. T>Данный режим может быть отменен с помощью вызова T>
Ytz>>Любой юзабилист скажет, что профессиональные приложения не используют одновременно по 10 окон.
K13>Особенно -- на весь экран.
K13>Нам хватает одного "полноэкранного", чтобы работать с кучей документов через закладки.
Хорошо, не спорю, 10 одновременных полноэкранных диалогов это чересчур.
Но насколько я понимаю, такая техника, при которой окно после закрытия не удаляется, а лишь скрывается для возможного последующего использования, является вполне обычной. (По крайней мере видел это в примерах в "qt 4 программирование gui на с++"). В этом случае эти скрытые, но неудаленные окна окна съедят достаточно большое количество памяти.
Хорошо, K13, если для вас это не проблема и вы занимаетесь профессиональной разработкой, напишите пожалуйста требования по памяти вашего ПО, просто что бы знать что сейчас является нормой.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, K13, Вы писали: K13>>Нам хватает одного "полноэкранного", чтобы работать с кучей документов через закладки.
PD>А закладки — не окна ?
К13 тут правильно сказал. Закладки проблему отчасти решают из за того, что менеджер окон qt хранит в буфере только то что нужно отображать при перерисовке окна. Если из 10 закладок активна одна, то для остальных видимо буфер создаваться не будет, так как они не нужны для отрисовки окна.
Re[9]: [qt] рсход памяти
От:
Аноним
Дата:
16.11.09 13:38
Оценка:
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, Аноним, Вы писали: А>>http://doc.trolltech.com/4.5/qt.html#WidgetAttribute-enum А>>This flag is only supported on X11 and it disables double buffering. А>>Само собой не помогает T>вранье: T>
Зачем же так грубо. Неужели вы думаете я бы стал создавать ветку только для того, что бы ввести кого то в заблуждение. Мне, например, очень интересно, как у вас получился такой результат.
На моей конфигурации (qt 4.5, msvc-2008) пример с сотней диалогов отожрал 450 метров опреативы
Здравствуйте, Аноним, Вы писали:
А>К13 тут правильно сказал. Закладки проблему отчасти решают из за того, что менеджер окон qt хранит в буфере только то что нужно отображать при перерисовке окна. Если из 10 закладок активна одна, то для остальных видимо буфер создаваться не будет, так как они не нужны для отрисовки окна.
Очень интересно. А при переключении закладок , выходит, буфер будет создаваться и все что надо, на нем рисоваться ? Или один буфер на все закладки и при переключении закладок перерисовать его для другой закладки ? В принципе такое возможно, но как-то очень уж непривычно. Опять же, для этого надо заставить закладку себе перерисовать исходя из каких-то иных данных, а как ?
With best regards
Pavel Dvorkin
Re[9]: [qt] рсход памяти
От:
Аноним
Дата:
16.11.09 13:46
Оценка:
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, Аноним, Вы писали: А>>http://doc.trolltech.com/4.5/qt.html#WidgetAttribute-enum А>>This flag is only supported on X11 and it disables double buffering. А>>Само собой не помогает T>вранье: T>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Аноним, Вы писали:
А>>К13 тут правильно сказал. Закладки проблему отчасти решают из за того, что менеджер окон qt хранит в буфере только то что нужно отображать при перерисовке окна. Если из 10 закладок активна одна, то для остальных видимо буфер создаваться не будет, так как они не нужны для отрисовки окна.
PD>Очень интересно. А при переключении закладок , выходит, буфер будет создаваться и все что надо, на нем рисоваться ? Или один буфер на все закладки и при переключении закладок перерисовать его для другой закладки ? В принципе такое возможно, но как-то очень уж непривычно. Опять же, для этого надо заставить закладку себе перерисовать исходя из каких-то иных данных, а как ?
Я высказываю лишь свое предположение, основанное на некоторых тестах. Например если открыть qt assistan, и начать создавать вкладки, то на каждую уйдет примерно 0,5-1 мб, а не 4-5, как если бы это было новое окно. Наверное это объясняется тем, что backingstore буффер относится к классу QWidget и ничего не знает о закладках, да и не должен знать, основная его цель — хранить то, что видит пользователь.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, trdm, Вы писали:
T>>Здравствуйте, Аноним, Вы писали: А>>>http://doc.trolltech.com/4.5/qt.html#WidgetAttribute-enum А>>>This flag is only supported on X11 and it disables double buffering. А>>>Само собой не помогает T>>вранье: T>>
А>а в виртуальной сколько?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, trdm, Вы писали: А>Зачем же так грубо.
сори А>Неужели вы думаете я бы стал создавать ветку только для того, что бы ввести кого то в заблуждение.
не а. А>Мне, например, очень интересно, как у вас получился такой результат. А>На моей конфигурации (qt 4.5, msvc-2008) пример с сотней диалогов отожрал 450 метров опреативы
Qt4.3.4
C:\>gcc --version
gcc (GCC) 3.4.2 (mingw-special)
Win XP SP2.
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, trdm, Вы писали: А>>Зачем же так грубо. T>сори А>>Неужели вы думаете я бы стал создавать ветку только для того, что бы ввести кого то в заблуждение. T>не а. А>>Мне, например, очень интересно, как у вас получился такой результат. А>>На моей конфигурации (qt 4.5, msvc-2008) пример с сотней диалогов отожрал 450 метров опреативы T>Qt4.3.4 T>C:\>gcc --version T>gcc (GCC) 3.4.2 (mingw-special) T>Win XP SP2.
Странно, очень странно. Проверил с вашим компилятором, все так же как и было
PD>Здравствуйте, K13, Вы писали: K13>>Нам хватает одного "полноэкранного", чтобы работать с кучей документов через закладки.
PD>А закладки — не окна ?
буфер создается на каждое top-level окно.
Если в него засандалить хоть сотню чайлдов друг в друге, каждый уменьшая в размере на пару пикселов -- ничего осбо страшного по памяти не произойдет.
вообще хочется понять, откуда берется куча top-level widgets на весь экран.
Какой смысл "хранить" виджеты? Данные должны лежать отдельно. Надо показать -- создал, показал.
Какой-нибудь toolbar -- ради бога, пусть болтается вечно через show/hide, как и Find/Replace Dialog.
Только стоит ли беспокоиться о памяти, выделенной под их буфер?
Можно привести пример workflow, при котором возникает необходимость иметь кучу top-level widgets, и каждый -- на весь экран?
А>Хорошо, K13, если для вас это не проблема и вы занимаетесь профессиональной разработкой, напишите пожалуйста требования по памяти вашего ПО, просто что бы знать что сейчас является нормой.
it depends
У разных продуктов по разному. Некоторым продуктам не хватает 2 гигов адресного пространства, приходится подключать "свой своп".
Разумеется, переход на 64 бита решил бы проблему без такого велосипеда, но у большинства кастомеров стоит 32-битная система.
Когда в результате тестового прогона выясняется, что общий объем данных вылез за 5 гигов, мне совершенно неинтересны 5 метров бэкбуффера на основное окно приложения.
Здравствуйте, kinetix, Вы писали: K>Здравствуйте, trdm, Вы писали: А>>>Мне, например, очень интересно, как у вас получился такой результат. А>>>На моей конфигурации (qt 4.5, msvc-2008) пример с сотней диалогов отожрал 450 метров опреативы T>>Qt4.3.4 T>>C:\>gcc --version T>>gcc (GCC) 3.4.2 (mingw-special) T>>Win XP SP2.
K>Странно, очень странно. Проверил с вашим компилятором, все так же как и было K>Неужели версия qt так влияет
Вполне может быть.
Я в последнее время для себя решил провести такую политику:
Не использую новые объекты, которые появляются там в 4.4 или 4.5
Стараюсь писать софт на объектах имеющихся в 4.2.1
А то жирнее становится библиотека, неповоротливее.
Достаточно написать приемлемый набор компонент для работы,
а остальное оставить за бортом. Специфика моего софта это позволяет.