Скорее - стек применяемых технологий. Например: C++, Boost, WIN32 API, etc.. А то с ограничениями на бинарик гарантированно придёшь к тому, что сейчас происходит у меня под носом: начальник требует ремонта за 8 часов, при том что список работ на 20 часов, которые нельзя выполнить параллельно, а только одну после другой.
Там очень много причинно-следственных связей, которые влияют на скрытие/отображение заполняемых полей, а также SQL, так что Qt не особо поможет даже в интерфейсе: всё равно вся работа это поведение.
А ответ на ваш вопрос очевиден, поэтому даже отвечать не стану. Но очевиден и результат, о котором, собственно и пишет автор.
Нужно думать как решить проблему, а причин не решать я и сам десяток не задумываясь набросаю.
Мне как-то дали заказ - воспроизвести функционал программы. Оригинал был написан на Qt, весил 60 с лишним мегабайт, а папка после установки уже около 300мб. Моя реализация с тем же функционалом, но написанная на чистом c++ с GDI/GDI+ и с SQLite на борту заняла 1,9мб (и это с картинкой на бэкграунде). Установка вообще не нужна, запускается как калькулятор, коим, собственно и является программа (только узкоспециализированный). Полностью поддерживаю крик души автора. А аргументы о том, что дешевле купить дополнительное железо, нежели год платить зарплату программистам, для меня разбиваются о затратах на ту же электроэнергию затраченную на время установки/запуска, если вдруг программа взлетела до миллионов установок. Понятно, что платит за это уже конечный потребитель, но тут как в анекдоте - зато ВВП выросло...
Меня тоже не покидает ощущение, что чем выше язык, тем больше ресурсы используются на переливание из пустого в порожнее. Однажды увидел тут на Хабре фрактал (множество) Мандельброта реализованный на чистом C. Чтобы понять, насколько быстрый алгоритм реализован там, запилил свой на Асм, с распараллеливанием расчётов в SIMD инструкциях процессора и в 8 потоков. Так вот, даже по сравнению с языком C, выигрыш был 5-6 раз. И это с выводом на экран. (Возможно, когда разгребу дела, выложу процесс написания и результат). Сам собой напрашивается вопрос - не многовато ли мы используем энергии процессоров просто на отопление помещений без какой-либо полезной работы.. Особенно это заметно на всяких, прости г-ди, python...
Скорее - стек применяемых технологий. Например: C++, Boost, WIN32 API, etc..
А то с ограничениями на бинарик гарантированно придёшь к тому, что сейчас происходит у меня под носом: начальник требует ремонта за 8 часов, при том что список работ на 20 часов, которые нельзя выполнить параллельно, а только одну после другой.
Там очень много причинно-следственных связей, которые влияют на скрытие/отображение заполняемых полей, а также SQL, так что Qt не особо поможет даже в интерфейсе: всё равно вся работа это поведение.
А ответ на ваш вопрос очевиден, поэтому даже отвечать не стану. Но очевиден и результат, о котором, собственно и пишет автор.
Нужно думать как решить проблему, а причин не решать я и сам десяток не задумываясь набросаю.
Мне как-то дали заказ - воспроизвести функционал программы. Оригинал был написан на Qt, весил 60 с лишним мегабайт, а папка после установки уже около 300мб. Моя реализация с тем же функционалом, но написанная на чистом c++ с GDI/GDI+ и с SQLite на борту заняла 1,9мб (и это с картинкой на бэкграунде). Установка вообще не нужна, запускается как калькулятор, коим, собственно и является программа (только узкоспециализированный).
Полностью поддерживаю крик души автора. А аргументы о том, что дешевле купить дополнительное железо, нежели год платить зарплату программистам, для меня разбиваются о затратах на ту же электроэнергию затраченную на время установки/запуска, если вдруг программа взлетела до миллионов установок. Понятно, что платит за это уже конечный потребитель, но тут как в анекдоте - зато ВВП выросло...
Конечно читал, просто именно про алгоритмическую оптимизацию сказать было нечего, а про ускорение работы программ в целом я любитель поговорить:)
Меня тоже не покидает ощущение, что чем выше язык, тем больше ресурсы используются на переливание из пустого в порожнее. Однажды увидел тут на Хабре фрактал (множество) Мандельброта реализованный на чистом C. Чтобы понять, насколько быстрый алгоритм реализован там, запилил свой на Асм, с распараллеливанием расчётов в SIMD инструкциях процессора и в 8 потоков. Так вот, даже по сравнению с языком C, выигрыш был 5-6 раз. И это с выводом на экран. (Возможно, когда разгребу дела, выложу процесс написания и результат). Сам собой напрашивается вопрос - не многовато ли мы используем энергии процессоров просто на отопление помещений без какой-либо полезной работы.. Особенно это заметно на всяких, прости г-ди, python...