Где можно узнать какой компонент на сколько увеличивает экзешник?

Форум — Ответы ( К темам )

? ACD: Где можно узнать какой компонент на сколько увеличивает экзешник? (29-03-2003 03:32:48)
Где можно узнать какой компонент на сколько увеличивает экзешник?
...какая функция за сколько тактов выполняется?
(кроме измерения "вручную")
Георгий (29-03-2003 12:15:35)

о размерах — при использовании стандартных компонентов >2 MB не будет...
основное место занимают текстовые таблицы и жуткое количество рисунков (BMP, ICO, CUR), причём не обязательно их использовать в программе — они добавляются вместе с компонентами — зачем добавляются — надо у Borland`а спросить...

можно провести эксперимент:
PE написанная на ASM, скомпилированная WASM и слинкованная WLINK сжимается UPX на 2-5%
PE созданная в BCB жмётся UPX`ом на 2-5 (чего бы вы думали) РАЗА

наличие рисунков легко проверяется с пом. любого т.н. "хакерского" редактора PE, который умеет с ресурсами работать...

Для BCB я нормальных профайлеров не видел.
А в ручную — это ты так RDTSC называешь?
но считать число тактов на выполнение процедуры в многозадачной ОС особого смысла не имеет.

ACD (30-03-2003 04:40:17)

" — при использовании стандартных компонентов >2 MB не будет..." — не утешительно.
Разъясните plz термины PE и RDTSC.
про такты — согласен , вопрос сформулировал не так , точнее меня интересует
объем кода а еще точнее где можно почитать исходники WinApi(и прочих) функций?
А про компоненты — где нибудь есть информаця на сколько какой компонент увеличивает размеры .exe и сколько памяти он занимает при выполнении процесса.

спасибо за ответ.

Георгий (30-03-2003 21:46:26)

PE:
Все Windows-приложения используют специальный формат исполнимых файлов — формат PE (Portable Executable). Такие файлы начинаются как обычные EXE-файлы старого образца (их также называют MZ по первым двум символам заголовка), и, если такой файл запустить из DOS, он выполнится и выдаст сообщение об ошибке (текст сообщения зависит от используемого компилятора), в то время как Windows заметит, что после обычного MZ-заголовка файла идёт PE-заголовок, и запустит приложение.

Георгий (30-03-2003 21:49:59)

Помещает в регистровую пару EDX:EAX текущее значение счётчика тактов — 64-битового машинно-специфичного регистра TSC, значение которого увеличивается на 1 каждый такт процессора с момента его последней перезагрузки.

Взято из книги Assembler написанной Зубковым С.В. и изданной ДМК в 1999г.

об исходниках WinAPI — это фактически исходники Windows — они с недавнего времени доступны представителям государственных организаций (фактически военным), но только для ознакомления с ними (т.е. смотреть глазами можно но не более)

По поводу памяти — неужели сейчас, когда обьём оперативной памяти исчисляется сотнями мегабайт, а операционная система (при наличии поддержки со стороны аппаратуры) реализует систему виртуальной памяти, которая расширяет обьём доступной для приложений оперативной памяти до 4GB, всё ещё возникает НЕОБХОДИМОСТЬ в создании компактных приложений?
По моему на данный момент программирование переросло из научно — исследовательской деятельности в производство, что привело к актуальности других критериев: скорость выполнения работ (написание программы) и качество (надёжность выполнения заявленных функций). В редких случаях, когда актуальна производительность программы, выполняют т.н. оптимизацию ПО — переписка отдельных частей кода с использованием более эффективных алгоритмов и только в случае крайней нужды прибегают к рассчёту числа байт кода и тактов выполнения процедур...

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

Георгий (30-03-2003 21:50:38)

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

Владимир (31-03-2003 00:27:23)

Если стоит вопрос о компактности кода и это очень важно,
то надо переходить на Visual C++, он генерит значительно
компактнее код, чем С++Builder, если-же важна скорость разрабоки
и удобство, и также вохможность быстрой доделки/переделки/изменения
программы, то выигрыш явно за C++Builder

Как правильно сказал Георгий — выбирайте, что вам важнее.
(обьём оперативной памяти исчисляется сотнями мегабайт,
а винчестера — десятками дешевых гигабайт)

ACD (31-03-2003 03:37:17)

Согласен что на первом месте идут скорость и надежность программы.Но всеже помоему размер .exe тоже играет не последнюю роль.Если можно не теряя в первых
двух критериях сделать прогу(на диске , а не в виртуальной памяти)меньше то к этому нужно стремиться.
А про измерение времени затраченного на выполнение определенного участка кода
программы в мультизадачной ос (win32) нашел у Рихтера очень красивый пример -
там учитывается переключение потоков.
Однажды я написал две абсолютно идентичные консольные програмки на VC++ 6.0 и
Builder 5.0 програмка на билдере была более чем в два раза меньше.(Может я что
то в опциях VC++ напорол)
К стати везде слышу , что программы на VC++ надежнее чем на Builder и Delfi это
в самом деле так ?

спасибо за ответы.

Георгий (31-03-2003 09:26:43)

"К стати везде слышу , что программы на VC++ надежнее чем на Builder и Delfi это
в самом деле так ?"

Надёжность программ полностью определяется программистом (а вернее оплатой его времени)!
За BCB и Delphi часто садятся люди, которые не понимают, что делают — примеров даже в этом форуме море, а за VC сесть можно, но у него более сложный процесс проектирования программ и это этих людей отпугивает. Вот и результат на VC обычно пишут квалифицированные программисты...
Но у Borland есть ряд глюков, которые заставляют программистов напрягаться, чтоб потом не мучиться с ними, например очень удивительно работающий BDE, не любящий много поточность VCL, но если не использовать BDE и самому реализовать последовательный или из главного потока доступ к VCL обьектам, то работать будет нормально.

Самая большая надёжность на данный момент у JAVA — если все библиотечные классы реализованы корректно, то писать можно очень криво, но машину (сервер) не повесишь.

Покажи Рихтеровский пример.

ACD (02-04-2003 03:38:53)

Пример Рихтера:

__int64 FileTimeToQuadWord(PFILETIME pft)
{
return(Int64ShlMod32(pft->dwHighDateTime,32) | pft->dwLowDateTime);
}

void LongOperation()
{
FILETIME ftKernelTimeStart,ftKernelTimeEnd,ftUserTimeStart,ftUserTimeEnd,ftDummy;
__int64 qwKernelTimeElapsed,qwUserTimeElapsed,qwTotalTimeElapsed;

GetThreadTimes(GetCurrentThread(),&ftDummy,&ftDummy,&ftKernelTimeStart,&ftUserTimeStart);

//здесь измеряемый код

GetThreadTimes(GetCurrentThread(),&ftDummy,&ftDummy,&ftKernelTimeEnd,&ftUserTimeEnd);

qwKernelTimeElapsed=FileTimeToQuadWord(&ftKernelTimeEnd)-FileTimeToQuadWord(&ftKernelTimeStart);
qwUserTimeElapsed=FileTimeToQuadWord(&ftUserTimeEnd)-FileTimeToQuadWord(&ftUserTimeStart);
qwTotalTimeElapsed=qwKernelTimeElapsed+qwUserTimeElapsed;
}

Ложка дегтя:В w9x GetThreadTimes и GetProcessTimes определены но не реализованы.

?	ACD: Где можно узнать какой компонент на сколько увеличивает экзешник? (29-03-2003 03:32:48)
Где можно узнать какой компонент на сколько увеличивает экзешник? ...какая функция за сколько тактов выполняется? (кроме измерения "вручную")
Георгий (29-03-2003 12:15:35)
о размерах — при использовании стандартных компонентов >2 MB не будет... основное место занимают текстовые таблицы и жуткое количество рисунков (BMP, ICO, CUR), причём не обязательно их использовать в программе — они добавляются вместе с компонентами — зачем добавляются — надо у Borland`а спросить... можно провести эксперимент: PE написанная на ASM, скомпилированная WASM и слинкованная WLINK сжимается UPX на 2-5% PE созданная в BCB жмётся UPX`ом на 2-5 (чего бы вы думали) РАЗА наличие рисунков легко проверяется с пом. любого т.н. "хакерского" редактора PE, который умеет с ресурсами работать... Для BCB я нормальных профайлеров не видел. А в ручную — это ты так RDTSC называешь? но считать число тактов на выполнение процедуры в многозадачной ОС особого смысла не имеет.
ACD (30-03-2003 04:40:17)
" — при использовании стандартных компонентов >2 MB не будет..." — не утешительно. Разъясните plz термины PE и RDTSC. про такты — согласен , вопрос сформулировал не так , точнее меня интересует объем кода а еще точнее где можно почитать исходники WinApi(и прочих) функций? А про компоненты — где нибудь есть информаця на сколько какой компонент увеличивает размеры .exe и сколько памяти он занимает при выполнении процесса. спасибо за ответ.
Георгий (30-03-2003 21:46:26)
PE: Все Windows-приложения используют специальный формат исполнимых файлов — формат PE (Portable Executable). Такие файлы начинаются как обычные EXE-файлы старого образца (их также называют MZ по первым двум символам заголовка), и, если такой файл запустить из DOS, он выполнится и выдаст сообщение об ошибке (текст сообщения зависит от используемого компилятора), в то время как Windows заметит, что после обычного MZ-заголовка файла идёт PE-заголовок, и запустит приложение.
Георгий (30-03-2003 21:49:59)
Помещает в регистровую пару EDX:EAX текущее значение счётчика тактов — 64-битового машинно-специфичного регистра TSC, значение которого увеличивается на 1 каждый такт процессора с момента его последней перезагрузки. Взято из книги Assembler написанной Зубковым С.В. и изданной ДМК в 1999г. об исходниках WinAPI — это фактически исходники Windows — они с недавнего времени доступны представителям государственных организаций (фактически военным), но только для ознакомления с ними (т.е. смотреть глазами можно но не более) По поводу памяти — неужели сейчас, когда обьём оперативной памяти исчисляется сотнями мегабайт, а операционная система (при наличии поддержки со стороны аппаратуры) реализует систему виртуальной памяти, которая расширяет обьём доступной для приложений оперативной памяти до 4GB, всё ещё возникает НЕОБХОДИМОСТЬ в создании компактных приложений? По моему на данный момент программирование переросло из научно — исследовательской деятельности в производство, что привело к актуальности других критериев: скорость выполнения работ (написание программы) и качество (надёжность выполнения заявленных функций). В редких случаях, когда актуальна производительность программы, выполняют т.н. оптимизацию ПО — переписка отдельных частей кода с использованием более эффективных алгоритмов и только в случае крайней нужды прибегают к рассчёту числа байт кода и тактов выполнения процедур... Советую тебе более точно оценить необходимость знания размеров компонентов, тем более, что мне не известны ни размеры компонентов, ни занимаемая ими память. Я даже не встречал упоминаний о размерах из официальных источников...
Георгий (30-03-2003 21:50:38)
в начало пред поста — описание команды RDTSC
Владимир (31-03-2003 00:27:23)
Если стоит вопрос о компактности кода и это очень важно, то надо переходить на Visual C++, он генерит значительно компактнее код, чем С++Builder, если-же важна скорость разрабоки и удобство, и также вохможность быстрой доделки/переделки/изменения программы, то выигрыш явно за C++Builder Как правильно сказал Георгий — выбирайте, что вам важнее. (обьём оперативной памяти исчисляется сотнями мегабайт, а винчестера — десятками дешевых гигабайт)
ACD (31-03-2003 03:37:17)
Согласен что на первом месте идут скорость и надежность программы.Но всеже помоему размер .exe тоже играет не последнюю роль.Если можно не теряя в первых двух критериях сделать прогу(на диске , а не в виртуальной памяти)меньше то к этому нужно стремиться. А про измерение времени затраченного на выполнение определенного участка кода программы в мультизадачной ос (win32) нашел у Рихтера очень красивый пример - там учитывается переключение потоков. Однажды я написал две абсолютно идентичные консольные програмки на VC++ 6.0 и Builder 5.0 програмка на билдере была более чем в два раза меньше.(Может я что то в опциях VC++ напорол) К стати везде слышу , что программы на VC++ надежнее чем на Builder и Delfi это в самом деле так ? спасибо за ответы.
Георгий (31-03-2003 09:26:43)
"К стати везде слышу , что программы на VC++ надежнее чем на Builder и Delfi это в самом деле так ?" Надёжность программ полностью определяется программистом (а вернее оплатой его времени)! За BCB и Delphi часто садятся люди, которые не понимают, что делают — примеров даже в этом форуме море, а за VC сесть можно, но у него более сложный процесс проектирования программ и это этих людей отпугивает. Вот и результат на VC обычно пишут квалифицированные программисты... Но у Borland есть ряд глюков, которые заставляют программистов напрягаться, чтоб потом не мучиться с ними, например очень удивительно работающий BDE, не любящий много поточность VCL, но если не использовать BDE и самому реализовать последовательный или из главного потока доступ к VCL обьектам, то работать будет нормально. Самая большая надёжность на данный момент у JAVA — если все библиотечные классы реализованы корректно, то писать можно очень криво, но машину (сервер) не повесишь. Покажи Рихтеровский пример.
ACD (02-04-2003 03:38:53)
Пример Рихтера: __int64 FileTimeToQuadWord(PFILETIME pft) { return(Int64ShlMod32(pft->dwHighDateTime,32) \| pft->dwLowDateTime); } void LongOperation() { FILETIME ftKernelTimeStart,ftKernelTimeEnd,ftUserTimeStart,ftUserTimeEnd,ftDummy; __int64 qwKernelTimeElapsed,qwUserTimeElapsed,qwTotalTimeElapsed; GetThreadTimes(GetCurrentThread(),&ftDummy,&ftDummy,&ftKernelTimeStart,&ftUserTimeStart); //здесь измеряемый код GetThreadTimes(GetCurrentThread(),&ftDummy,&ftDummy,&ftKernelTimeEnd,&ftUserTimeEnd); qwKernelTimeElapsed=FileTimeToQuadWord(&ftKernelTimeEnd)-FileTimeToQuadWord(&ftKernelTimeStart); qwUserTimeElapsed=FileTimeToQuadWord(&ftUserTimeEnd)-FileTimeToQuadWord(&ftUserTimeStart); qwTotalTimeElapsed=qwKernelTimeElapsed+qwUserTimeElapsed; } Ложка дегтя:В w9x GetThreadTimes и GetProcessTimes определены но не реализованы.