» Вопросы по Embarcadero RAD Studio XE4

Mikanoshi

Цитата:

Это не помогает, удаляется только доп. RTTI, а не всё.

Пересобери RTL изменив в system.pas Default RTTI settings

Цитата:

Пересобери RTL изменив в system.pas Default RTTI settings

Ты пробовал так сделать? Я убрал строки

Код: {$RTTI INHERIT
METHODS(DefaultMethodRttiVisibility)
FIELDS(DefaultFieldRttiVisibility)
PROPERTIES(DefaultPropertyRttiVisibility)}

Цитата:

TypInfo, короче переписывать чтоли сорцы делфи из-за этого все?)

Всего-навсего.
Либо использовать более раннюю версию студии, если так важен небольшой размер файла.

Mikanoshi

Цитата:

System.Rtti всё равно добавляется в экзе

А ты уверен, что пересобрал RTL? Сам по себе этот модуль не разувает экзешник. Экзешки пухнут от того, что компилятор сует туда RTTI. А в system.rtti.pas всего лишь обертки для удобного использования этих данных, доступ к которым можно получить и без system.rtti.pas через system.typinfo.pas

valgreesh
Удалил System.dcu и перекомпилил вместе с SysInit.pas, именно System.Rtti и раздувает exe, в .map видно:


Даже в ресурсах в RCData/PACKAGEINFO прописано:

Цитата:

Package Info (Delphi or C++ Builder)
PackageInfo: 0x8C100000
Flags:
Type: library
Compiler: produced with Delphi 4 or higher

Contained Units:
...
System.Rtti [ImplicitUnit]
...

Цитата:

Это как посмотреть, 32 приложение под WOW64 потребляет больше памяти и работает незначительно медленнее:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384219(v=vs.85).aspx

по той ссылке нет ничего значительного. А 32-разрядные операции, особенно тяжелые, вроде умножения и деления, -- наверняка быстрее 64-разрядных.

Напротив, общеизвестно, что 64-разрядное приложение потребляет больше памяти. Ибо любой указатель, интерфейс, переменная-класс, строка и т.д. -- все это жирнее в 64 разрядном режиме.


Цитата:

Это не помогает, удаляется только доп. RTTI, а не всё.

блин, напиши стоящее, востребованное приложение, и никто не посмотрит на его размер. Кому сейчас интересен размер Firefox, Chrome , Opera, IE? Сравнивают их по другим совершенно параметрам.

Добавлено:

Цитата:

Пересобери RTL изменив в system.pas Default RTTI settings

это опасная операция. dcu и исходники RTL нередко не соответсвуют полностью.

Mikanoshi

Цитата:

Удалил System.dcu и перекомпилил вместе с SysInit.pas

Это все что угодно, тольно не перекомпиляция rtl. Давай по шагам что делал.


Цитата:

именно System.Rtti и раздувает exe, в .map видно

Я пересобрал rtl Delphi XE4 с отключением rtti. Размер дефолтного VCL проекта с одной формой и в режиме сборки release уменьшился с 2 325 504 байт до 1 233 920 байт. И судя по *.map файлу размер system.rtti.pas там всего 208 байт.

AlekXL

Цитата:

это опасная операция. dcu и исходники RTL нередко не соответсвуют полностью.

Ничего опасного, пересобирай без замещения и всех делов.

Цитата:

блин, напиши стоящее, востребованное приложение, и никто не посмотрит на его размер. Кому сейчас интересен размер Firefox, Chrome , Opera, IE? Сравнивают их по другим совершенно параметрам.

Выше было написано зачем маленький размер.

Цитата:

Это все что угодно, тольно не перекомпиляция rtl. Давай по шагам что делал.

Напиши мне что поменять в сорце, а я уж перекомпилю, там есть cmd даже для этого. Я просто один System.pas скомпилировал.

Mikanoshi

Цитата:

Напиши мне что поменять в сорце, а я уж перекомпилю, там есть cmd даже для этого

В system.pas отключаешь дефолтные настройки RTTI и включаешь минимальные. Там по комментариям все понятно. Потом собираешь rtl тем самым батником или открыв пакет buildWinRtl. dcu'хи новой rtl падают в \общие документы\RAD Studio\lib\win\[release|debug]. Потом в своем проекте в путях поиска прописываешь этот самый путь с новой rtl. Если проект тянет за собой еще и vlc, в пути поиска прописываешь путь к исходникам vcl - она тоже должна будет пересобраться. Не забывать, что настройки для release и debug разные. Чтобы быть уверенным, что ты собираешь проект со своей измененной rtl, вsystem.pas можно добавить какую-нибудь глобальную функцию, а в своем проекты попробовать её вызвать - если проект соберется, значит rtl твоя.


Цитата:

Я просто один System.pas скомпилировал.

Мне конечно пофиг, но как у тебя потом проект собрался с одной измененной dcu'шкой? Изменение system.pas влечет за собой перекомпиляцию вообще всего, что используется в проекте.

Цитата:

Мне конечно пофиг, но как у тебя потом проект собрался с одной измененной dcu'шкой?

Без понятия)) запустил dcc32.exe с параметрами и System.pas, новые dcu появились, их скопировал в lib\win32\release, в проекте выбран этот профиль.

Добавлено:
Пересобрал, System.Rtti стал в 2 раза меньше, что-то ещё где-то надо изменить похоже...

Mikanoshi

Цитата:

Ну 21 век, скоро всё будет 64-битное, так что всё равно придётся.

64 бита не даёт какое-то подавляющее преимущество, поэтому вытеснение будет долгое и нудное. ИМХО сейчас совершенно необязательно гнаться за 64 битами...

karlss0n
У меня шелл применяет скины только окнам 64-битных прог, для меня этого достаточно, чтобы желать 64-битную прогу и переписать под неё все плагины

Mikanoshi

Цитата:

Пересобрал, System.Rtti стал в 2 раза меньше, что-то ещё где-то надо изменить похоже...

А это уже нужно смотреть, где этот rtti используется. В rtl всего три (classes, objauto, typinfo) модуля подключают его. В classes он используется для сериализации, в objauto для динамического вызова методов, в typinfo в методах используемых сериализатором. За рамками rtl он еще используется в биндингах, bd, и обезьяне. Теперь смотри, какой код ты используешь у себя, хотя 100 килобайт на код rtti.pas не так уж и много - иконка весит больше

Цитата:

иконка весит больше

нифига у тебя иконки

Mikanoshi

Цитата:

нифига у тебя иконки

Да это не у меня, это дефолтная иконка дельфей весит почти 300Кб. Что в общем нормально, начиная с висты.

Я думаю, что все эти операции по уменьшению размера ни к чему хорошему не приведут.
Если нужен маленький размер, просто стоит перейти на более раннюю версию, как я уже написал выше.

MGAlex

Цитата:

Я думаю, что все эти операции по уменьшению размера ни к чему хорошему не приведут.

Размер-то уменьшается, а это уже хорошо. И это, надо заметить, не хаки, а вполне законный путь. А вот дефолтное наличие RTTI для приватных членов это 100% не айс.

Отлично! Почистил Classes и TypInfo, Rtti полностью исчез из dll
Размер на 1.1% больше, чем в ХЕ2. Если ничего не поломалось, то будет вообще замечательно)

Mikanoshi

Цитата:

Почистил Classes и TypInfo

А у тебя прямо или косвенно WriteComponent/WriteDescendent не вызывается случаем? Просто в дефолтном проекте с одной формой методы из system.rtti не задействуются безо всяких чисток.

WriteComponent используется, хотя сейчас смотрю на код и похоже этот код лишний)) Но всё равно с новым RTL работает нормально, я context удалил там какой-то в функции только.

Цитата:

Вот в MS Office с новым форматом docx, xlsx и т.д. размер файла стал меньше, чем doc, xls и др. И это показатель, на мой взгляд.

Вряд ли они этого добивались. Они просто второпях копировали OpenOffice.org, который к тому времени прошёл ECMA, шёл в ISO и мог реально стать единственным международным стандартом.

Добавлено:

Цитата:

а зачем?

ДУмаю, в основном - интеграция с оболочкой - разного рода Shell Extensions.

Добавлено:

Цитата:

Я думаю, что все эти операции по уменьшению размера ни к чему хорошему не приведут.

Ну я когда-то писал 2Кб DLL на D5

Такого на XE4 наверное действительно не повторить

Добавлено:

Цитата:

Недаром WinForms была слизана с VCL

Хммм... а не потому просто, что их писал один и тот же человек ?


Цитата:

vcl почти гениален по интуитивности и общей архитектуре.

В однопотоке ShowModal завешивает всю программу - интуитивно до жути.
В многопотоке очень опасно в другом потоке создать форму или обратиться к уже созданной. Очень интуитивно.
В неюникодной дельфи при копировании русского текста с контрола в clipboard надо клавиатуру на русский переключать (или патчить VCL) - очень интуитивно.
Форма освобождает непринадлежащие ей контролы (если они на ней лежат) - тоже интуитивно весьма...
Чтобы добавить пункт между двумя TMenuItem нужно у них найти родителя. А для TMAinMenu нужно найти виртуального родителя, которого не существует, но он есть. Ооочень интуитивно.
Про дополнение VCL (например вернуть в TMainMenu HelpBreak или добавить в чей-то TDataSet master-detail) я молчу - там интуитивность так и прёт, но это немного другой уровень.

В общем ты путаешь "понятность ежу" и свой опыт написания сотен программ за десятки лет и сотни книжек и сайтов по Delphi.


Цитата:

там таски зависимые друг от друга.

То есть тебе нужен планировщик. Да, OTL планировщиком не является, я тоже поначалу пытался из неё это сделать, а потом просто понял, что она не для этого.

Вот запускается винда, грузит драйвера, с учётом зависимостей. Занимается этим NT Services Manager. (На линуксах - init-scriptы или какая-то из десятка их подмен). Но мы же не говорим, что олт этого Service Manager стал библиотекой для распараллеливания.

И твой планировщик тоже ей не является - он для многопточностей клиент, а не провайдер. Его фнукции учёт и разрешение зависимостей, а многопоточность он *использует* и может использовтаь любую - TThread, BeginThread, AsyncCalls, OTL, whatever

Собственно, я согласен что для Delphi нет хорошего планировщика, может быть это слишком индивидуальная задача дял one size fits all библиотеки.
Но OTL - библиотека для распараллеливания поточных вычислений, и если в ней чего-то не хватает - так это поддержки и учёта разных исполнителей, в первую очередь GPGPU, а также дисков, сетевых нод.


Цитата:

 А проверка статуса  в многопоточном окружении -- требует блокировки

Пардон? прочитать булевскую переменную - типа TObject.Disposed, TThread.Terminated, TApplication.Terminated - требуйет блокировки???


Цитата:

Плюс к тому, нулевая кроссплатформенность из-за Windows Messaging

Это да. Но что характерно, никто на линукс или MacOS не перетащил. То ли не хотят, то ли не могут.


Цитата:

только в реальном мире задачи не столь однотипные

Ну так для этих задач OTL и не подходит.

Недаром он так вылизывал методы создания задач в два три предложения - OTL решает мелкие по коду, но затратные по данным вычисления. Графы зависимостей в неё не входят.

valgreesh

Цитата:

В system.pas отключаешь дефолтные настройки RTTI и включаешь минимальные. Там по комментариям все понятно. Потом собираешь rtl тем самым батником или открыв пакет buildWinRtl. dcu'хи новой rtl падают в \общие документы\RAD Studio\lib\win\[release|debug]. Потом в своем проекте в путях поиска прописываешь этот самый путь с новой rtl. Если проект тянет за собой еще и vlc, в пути поиска прописываешь путь к исходникам vcl - она тоже должна будет пересобраться. Не забывать, что настройки для release и debug разные. Чтобы быть уверенным, что ты собираешь проект со своей измененной rtl, вsystem.pas можно добавить какую-нибудь глобальную функцию, а в своем проекты попробовать её вызвать - если проект соберется, значит rtl твоя.

Если так делать, то не находтся jdapimin.obj
который нужен для перекомпиляции VCL.Imaging.Jpeg

Где его искать?

karlss0n
В VCL нет упоминания о RTTI, можно не перекомпилировать. У меня работает и с родными dcu.

karlss0n
Здесь описана подобная проблема:
http://stackoverflow.com/questions/8432967/i-cant-work-with-jpeg-in-delphi-xe2

MGAlex

Цитата:

Здесь описана подобная проблема:
http://stackoverflow.com/questions/8432967/i-cant-work-with-jpeg-in-delphi-xe2

Там два решения описаны -
1. найти эти файлы и добавить в путь
2. не перекомпилировать VCL

Но задача стоит перекомпилировать VCL и файлов этих нет. У меня стоит XE2, в ней эти файлы есть (и сырцы на c, и скомпилированные в obj). Попробовал их, но результат, как и ожидалось - не хватает функций.

Доставил C++ Builder и вместе с ним доставились сырцы на библиотеку JPEG. Видимо логика если сырцы на c, то без него не скомпилять, а следовательно не фиг их ставить (хотя скомпиленные obj могли бы и с Delphi ставить).

можно, наверное, и выкинуть vcljpeg было бы. Взять вметсо него из graphicEx или из Vampyre Imaging

karlss0n
Решение там описывается следующим образом:


Цитата:

I suspect that your .dpr file contains references to a file named Vcl.Imaging.jpeg.pas. Solve the problem by removing the references to Vcl.Imaging.jpeg.pas from your .dpr file. Another explanation is that you have a source file named Vcl.Imaging.jpeg.pas in your search path.

Я подозреваю, что Ваш .dpr файл содержит ссылки на файл с именем Vcl.Imaging.jpeg.pas. Проблема решается путем удаления ссылок на Vcl.Imaging.jpeg.pas из Вашего .dpr файла. Либо в пути поиска указан файл с именем Vcl.Imaging.jpeg.pas

Видимо, имеется в виду, что в Library pass указан путь к этому файлу.

Цитата:

Плюс к тому, нулевая кроссплатформенность из-за Windows Messaging

Это да. Но что характерно, никто на линукс или MacOS не перетащил. То ли не хотят, то ли не могут.

У Gabr нету Mac - из-за этого проблемы с OSX. Технических проблем перетащить OTL на OSX нету. Сторонних людей, кромет Gabr, которые бы активно коммитили в OTL не замечено, поэтому если Gabr не может, то тупик))

Добавлено:

Цитата:

Вот в MS Office с новым форматом docx, xlsx и т.д. размер файла стал меньше, чем doc, xls и др. И это показатель, на мой взгляд.

Это показатель, только того, что тело документа вроде бы ZIP пакуется. Просто по сравнению с временем проектирования формата DOC выросли объемы доступной оперативной памяти, поэтому распаковка ZIP уже не проблема.

Цитата:

Это показатель, только того, что тело документа вроде бы ZIP пакуется. Просто по сравнению с временем проектирования формата DOC выросли объемы доступной оперативной памяти, поэтому распаковка ZIP уже не проблема.

На самом деле не важно за счет чего добились уменьшения размера, важен конечный результат.
Пусть и студии придуают какую-то архивацию, к примеру.

Я согласен, что сейчас размер +/- 10 Мб роли не играет, но все же.

MGAlex

Проблема заключалась в том, что при изменении RTL требуется полная перекомпиляция VCL (всё что зависит от RTL). Vcl.Imaging.jpeg - зависит, следовательно и перекомпилировать нужно.

Собственно задачу я решил, сырцы поставились вместе с cbuilder, скомпилял с помощью (может кому пригодится)

bcc32 -c -O2 -Oc -OS -d -w-par -w-aus -ff -pr -a4 -Ov -O -I..\..\tools\include *.c

В результате полностью пересобрать RTL и VCL удалось.

Я честно убедился, что RTTI теперь занимает сильно меньше и файл теперь вместо 69 метров - 67. Вернул всё обратно