» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

asutp2
Вот и разрываюсь между новыми возможностями и допотопными компьютерами, на которых работают 90% пользователей программы. И увеличение на несколько мегабайт - это уже перебор. Что же они делают такое от версии к версии, если функциональность скомпилированной программы не меняется, а размер значительно увеличивается?

Dronton2,
вы же используете DevExpress, что автоматически увеличивает размер самой скомпилированной программы в разы, вне зависимости от версии делфи. Так что плюс/минус пара мегабайт, зависящих исключительно от компилятора, как мне кажется погоды даже на допотопных компах не сделает.

asutp2
Пожалуй, перейду сначала на DevExpress v15, которая поддерживает Berlin, посмотрю на реакцию пользователей, и, если всё пройдёт нормально, перейду на Берлин или Токио, смотря что будет в то время актуально.
Спасибо за совет.

Dronton2


Цитата:

Что же они делают такое от версии к версии, если функциональность скомпилированной программы не меняется, а размер значительно увеличивается?

Я уже писал ранее, в этой ветке или соседней.

1) богаче становиться RTL/VCL
1.1) больше процедур
1.2) больше классов
1.3) больше методов.

2) больше ресурсов.

На размер влияет все.

Но если ресурсы, н-р скины, влияют на размер, в основном, на диске, то RTL/VCL линкуется в код.

Линкер уже не способен определить какая часть кода библиотек не применяется.
Это возможно сделать только статичных методов.
Встречается вызов virtual/dynamic - линкуется ВСЯ иерархия, что доступна(через USES).

Поэтому следим за USES.

Добавление DevExpress увеличивает размер на полтора десятка мегабайт.
Отключаем скины, вычищаем USES - и вот уже чуть меньше двух.

Размер сильно растет в мемент переключения/перехода/задействания тяжелой библиотеки.
Затем - сильно меньше.

asutp2

Цитата:

Хороший пример - parallel library

OmniThreadLibrary, бесплатно, с исходниками, тоже мощная штука, и не требует берлина.

Dronton2
Если речь идет лишь об уменьшении на 1-2 Мб размера файла, то попробуйте сжать UPX-ом. Он 8 Мб может упаковывать в 3 Мб.
Как вариант.

Zatupitel
поддерживаю. У меня основное приложение с 53 до 18 упаковывает (использую ключи --lzma --best)

Cryogen2003
Только надо учитывать, что после упаковки, на компьютере пользователя, расход оперативки увеличится на размер распакованного приложения.

Раздел uses был вычищен. На этом сэкономить не получилось.
Нашёл вот ещё способ уменьшения exe-шника:
http://ru.stackoverflow.com/questions/318452/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0-%D1%81%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F-%D0%B2-delphi-xe-%D0%BF%D0%BE%D1%87%D1%82%D0%B8-%D0%B2-2-%D1%80%D0%B0%D0%B7%D0%B0-%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%B5-%D1%87%D0%B5%D0%BC-%D0%B2-delphi
и полный список PE-флагов: http://docwiki.embarcadero.com/RADStudio/Seattle/en/PE_(portable_executable)_header_flags_(Delphi)

после этого, у меня размер exe-файла уменьшился с 32 до 28 Мб

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

Cryogen2003
Согласен, сейчас добавить 1 Гб памяти уже не та проблема, если это возможно в конкретном случае.

Cryogen2003
Помнится после распаковки экзешник полностью в оперативку ложился. Правда диспетчер задач это не покажет если не отобразить все колонки, которые посвящены памяти. Может сейчас UPX и поумнел...

Frodo_Torbins
а разве так же не происходит, когда обычный exe грузишь?

Cryogen2003

Цитата:

а разве так же не происходит, когда обычный exe грузишь?

Только в том случае, если системе не удаётся разместить модуль (любой, exe или dll) по его базовому адресу (задаётся в параметрах линкера). Если удаётся, то система использует файловый маппинг (образ модуля становится частью адресного пространства процесса) и в оперативную память подгружаются только реально используемые страницы. Ровно тот же принцип по которому работает файл подкачки.

Эмбаркадера как всегда в своем духе. Поют песни про качество продукта.
Хваленый DataSnap в 10.1 вызывает утечки в памяти по RTTI классам под высокой нагрузкой.
В XE6 такого нет, где качество.

И вообще, попробовав mORMot просто прифигел, какая разница в производительности.
Datasnap очень медленный если сравнивать, просто не прилично медленный.
Но и мормот имеет свои минусы, жаль Datasnap http.sys не поддерживает, глядишь скорость бы взлетела при публикации под windows.

SolidSnakeRU

Цитата:

жаль Datasnap http.sys не поддерживает

Спрашивал, искал, может кто уже интегрировал поддержку http.sys в WebBroker.
Тишина.
А было бы неплохо.

DataSnap эксплуатирует инфраструктуру WebBroker.

У меня self-hosted SOAP сервера в том числе.
А там Indy.

Нужен очень абстрактный слой сетевого взаимодействия, чтобы на винде, маке и линуксе использовались штатные сетевые механизмы для достижения высокой скорости и удобства разработки, в то время как инди должен оставаться чисто прозапас.
Например, с HTTP.sys требуется ряд не шибко удобных для разработчика операций, это и установка сертификата в хранилище сертификатов windows, регистрация сертификата для использования на порту прослушивания и собственно сама регистрации порта.
Надо еще не забывать удалять регистрацию своевременно.
И все эти заморочки только для windows, мак и линукс вообще в пролете.
Такой объем работы как раз работа для эмбаркадеро - поддержать нативные механизмы и обернуть все в абстрактный класс.
Видимо проще продавать подсветку блоков кода, чем реальные технологии для разработчиков.

kaz_av
Возможно upx так же работает, как и должен. Вроде в их исходниках видел mapping файла из swap

Cryogen2003
Вчера пробовал последний UPX, при запаковке без ключей, 32битный экзешник целиком оказывается в памяти после запуска, без сжатия процесс занимает куда меньше памяти.
Приходится выбирать что экономить: место на диске, память или трафик.
Сделать всё сразу не получится.
Сэкономить память и трафик = не использовать upx, сжимать установочный файл.
Сэкономить диск и трафик = пожать в upx, сжимать установочный пакет.
Если требуются постоянные обновления - на помощь приходит дифференциальное бинарное обновление. Это куда лучше чем компилировать программу с внешними пакетами.
Где-то в интернете даже есть проект такой в исходнике, качал, работает, но под современную среду требуется переделка кода.

SolidSnakeRU
(((( значит весь exe держат в памяти, жаль

Но мне без upx не жить. exe лежит на сетевом диске, оттуда лоадером вытягиваются все изменения по exe, отчетам, скинам в локальную папку пользователя, а оттуда уже запускается. В Москве в двух основных офисах проблем нет с запуском, а вот в различных отделениях Москвы и во всех регионах некоторый ужас с трафиком, приходится как-то так. С внешними пакетами (типа BPL) очень не удобно бывает - есть стандартные bpl среды, они не изменяются, но вот bpl с компонентами достаточно часто изменяются и тут получаются проблемы с обновлениями - выкачать обновленный exe сжатый upx часто проще, чем маленький exe (так же сжатый upx) и кучу 100500 различных bpl.

Добавлено:
SolidSnakeRU
Если найдешь ссылку на тот проект, скинь плиз, интересно почитать

Цитата:

Если найдешь ссылку на тот проект, скинь плиз, интересно почитать

Присоединяюсь к просьбе, т.к. ситуация примерно такая же.

Цитата:

32битный экзешник целиком оказывается в памяти после запуска

О каком объёме идёт речь, если не секрет?

подскажите пожалуйста как быстро и построчно прочитать огромный (от 500мб) текстовый файл?
желательно еще организовать Progresbar что бы пользователь видел что процесс идет

qwertEHOK
CreateFileMapping и MapViewOfFile тебе в помощь

apnss
Над ними кстати должны существовать какие то обертки. Потому что напрямую их дергать весьма сомнительное удовольствие.

Frodo_Torbins
я направление задал
да и юзал его еще на XP и каком-то древнем сабже тогда такой вариативности апишек не было
хотел у себя найти код, для примера - нету
вроде на торринет чтото было

Можно глянуть в сторону TGpTextFile

уж послали так послали

нашел вот такой unit
http://muonium.rgho.st/6sTnJK5pl

но на
var
b:TMappedMemoryStream;
line:string;
begin
b:=TMappedMemoryStream.Create(filename);
result:=0;
while not (b.EOF) do
begin
line:=b.ReadString;
inc(result);
end;
b.Free;
end;

ругается человеческим голосом. посмотрите своим опытным взглядом функцию ReadString



Добавлено:
кстати, пока самым быстрым идет обычный FileStream (правда в одном файле - за 800мб он самый последний)

в 10,1 добавили TBufferedFileStream http://docwiki.embarcadero.com/Libraries/Berlin/en/System.Classes.TBufferedFileStream

жаль пока не могу потестить ((

qwertEHOK
Поддержку NeoAnomaly, посоветую TGpTextFile.
Умеет читать и писать через буфер - по скорости очень нравится

вот результаты по скорости


первый файл 150 мб, с адресами (длинные строки)
второй файл - 320 мб, с цифрами

первое число это gettickcount
второе - количество строк

Добавлено:
NeoAnomaly
Cryogen2003
у TGpTextFile использует OTL
я поставил последний OTL, но что-то не то. тестовое приложение TGpTextFile работает

ругается OTL
[dcc32 Error] OtlCommon.pas(2904): E2003 Undeclared identifier: 'TSystemLogicalProcessorInformationArr'
[dcc32 Error] OtlCommon.pas(2908): E2003 Undeclared identifier: 'DSiGetLogicalProcessorInfo'
[dcc32 Fatal Error] GpHugeF.pas(373): F2063 Could not compile used unit 'OtlCommon.pas'

хотя все демо примеры работают