Comments 37
UFO just landed and posted this here
А это был hello world или сколько-нибудь вменяемое приложение?
В качестве приложения было выбрано обычное пустое окно
Ну то есть это вообще никак не показывает потребление памяти тулкитом, только его базовый footprint. Увы, исследование ни о чём. На той же виртуализации списков (или её отсутствии) разница может быть на порядки, причём как по потреблению памяти, так и по быстродействию.
Согласен, данное исследование носит весьма синтетический характер. С другой стороны, написание реального приложения для все перечисленных платформ — труд весьма кропотливый с одной стороны, с другой стороны объем данного приложения должен быть весьма большим, чтобы убрать синтетичность. Даже озвученный вами кейс с виртуализацией «выстреливает» далеко не всегда, да и к тому же на том же electron-е (не уверен, но я надеюсь и в других популярных GUI фреймворках) это легко реализуется.
Ну и в конце концов сам автор предупреждает, что научной ценности данный материал не несет. Так, забавы ради.
Ну и в конце концов сам автор предупреждает, что научной ценности данный материал не несет. Так, забавы ради.
с другой стороны объем данного приложения должен быть весьма большим, чтобы убрать синтетичность.
ListView на 100500 элементов уже был бы показательным. Например создает фреймворк 100500 элементов или ограничивается небольшим числом видимых элементов.
По мне так это ничуть не менее синтетично кейса из статьи. Никак не характеризует фреймворк.
Он характеризует по потреблению памяти, а не по размеру рантайма.
Замечу, что характеризует по потреблению памяти конкретно в кейсе со списком. Что уже сильно ограничивает применимость результатов.
Списки и таблицы распространенные компоненты. Делаете ли UI к базе данных или клиент к социалке с бесконечной лентой.
Я о другом: вы не сравниваете фреймворки, вы сравниваете реализации списков в разных фреймворках. Серьезных выводов о самом фреймворке вы не сделаете. Пример я уже привел выше — virtual scroll есть в electron (точнее в web фреймворках), и память, которую занимают элементы в DOM константна. Но что это вам говорит о фреймворке в целом?
сравниваете реализации
Вся статья о сравнение реализации. Вы сейчас пытаетесь увести с обсуждаемой темы.
Ничуть. В конце концов кейс со списками не я предложил) Я лишь пытаюсь доказать (и об этом я уже пишу из сообщения в сообщение), что сделать несинтетические всеобъемлющие тесты фреймворков (что сравнение однооконного приложения, что сравнение списка — это сугубо синтетические тесты, не отражающие реального положения дел) — это очень сложное дело, а тем более на таком количестве инструментов. Но статья и не претендует на всеобъемлющее исследование (о чем кстати там тоже написано).
Наоборот, как раз базовый футпринт весьма показателен. Дальнейшее увеличение приложения приведет к росту потреблению памяти по более пологой кривой.
Я 5 лет назад на предмет памяти смотрел расширенные примеры — грубо говоря окно, на котором отрисованы все элементы UI из библиотеки (обычно с каждой либой есть такой пример). Цифры были сравнимыми: 10-20 Мб частный рабочий набор.
Я 5 лет назад на предмет памяти смотрел расширенные примеры — грубо говоря окно, на котором отрисованы все элементы UI из библиотеки (обычно с каждой либой есть такой пример). Цифры были сравнимыми: 10-20 Мб частный рабочий набор.
UFO just landed and posted this here
Можете добавить AvaloniaUI?
github.com/AvaloniaUI/Avalonia
github.com/AvaloniaUI/Avalonia
Это перевод, судя по всему автор доступен в соответствующем посте на реддите. https://www.reddit.com/r/programming/comments/cr3tqx/comment/ex2f6g4
- нет исходного кода приложений, а значит hello world, который ничего не показывает;
- судя по цифрам, сюда включается разделяемые библиотеки.
Прошу прощения за оффтоп. Подскажите пожалуйста инженеру-конструктору, в чем можно создавать небольшие собственные проекты с оконным интерфейсом и привязкой на с++? Что-то на подобие HiASM`a.
QT и Qt Designer, думаю, должны подойти
С помощью Qt вообще реально получить exe'шник меньше 5 Мб? Да и даже для 5 Мб надо ещё сильно пошаманить со сборкой. Это просто раздутый монстр какой-то. Вот что они пихают в бинарник, что он так жиреет?
Вкратце — так устроен С++. Подробнее — смотреть .map от линкера.
На скорость (в т.ч загрузки) и потребляемую память влияет мало.
P.S.Я полагаю, что 5 Мб речь идет о статической сборке Qt, поскольку иначе 1.5-2Мб.
На скорость (в т.ч загрузки) и потребляемую память влияет мало.
P.S.Я полагаю, что 5 Мб речь идет о статической сборке Qt, поскольку иначе 1.5-2Мб.
EXE-файл Win64, создающий с помощью Qt окно, весит килобайт 50, дальше уже по мере добавления кода. Это при динамической линковке с Qt и рантаймом С++.
С++ «так» не устроен. Таким получается код, порождаемый набором внешне изящных и удобных, но сильно избыточных языковых конструкций. А поскольку большинство разработчиков давно забыло, как считать единицы мегабайт (считают в лучшем случае десятки), такой подход победным маршем идет по миру.
Как минимум, у кьютей почти вся своя стандартная библиотека и даже больше. Как максимум, я помню, что для отключения линковки с ICU надо было очень постараться.
Чтобы получить ТОЛЬКО экзешник с помощью Qt, вообще надо сильно пошаманить. Во всяком случае, я потратил довольно много времени, чтобы научиться самому собирать библиотеку статически (а всевозможные howto в мелочах устарели...). Но после этого достаточно навороченное приложение влезает в один файл на 10 мегабайт. С UPX'ом — в 4..5.
Если ещё актуально и нужен UI Designer, их имеют следующие библиотеки/фреймворки:
- Qt (Qt Designer или в целом IDE Qt Creator)
- Gtk (Glade или IDE Anjuta)
- wxWidgets (У них несколько собиралок, например wxformbuilder, а также собиралка в составе IDE Code::Blocks)
- FLTK (Fluid: позволяет ещё код и UI блоками собирать)
- JUCE (имеет где-то в комплекте странного вида IDE с собиралкой UI)
Хоть и electron в глубокой попе, всё же для большинства приложений это не главное. Как по мне скорость разработки важнее если не страдает быстродействие приложения.
Странно, что есть winapi, но нет cocoa.
Вот с HorusUI я ожидал примерной цифры в 20 Мб, т. к. он использует OpenGL и режим немедленной отрисовки GUI. Не понимаю, почему цифра вышла больше.
Замапил себе в процесс какой нибудь зашаренный фреймбуфер или пару оных для теневого свопа?
SWT отсутствует.
Без исходников непонятно, что они там накидали в Swing и JavaFx, может там неоптимальный подход.
Совершено не показательный результат. Для java судя по всему использовался запуск с дефолтными настройками, при которых jvm резервирует достаточно большое количество памяти. Вот и получается очередная мифология из серии C++ крутой, java тормозная (хотя это уже давно не так и производительность больших jvm приложений ни чуть не хуже плюсовой).
Sign up to leave a comment.
Сравнение потребления памяти различных GUI тулкитов