link1562 link1563 link1564 link1565 link1566 link1567 link1568 link1569 link1570 link1571 link1572 link1573 link1574 link1575 link1576 link1577 link1578 link1579 link1580 link1581 link1582 link1583 link1584 link1585 link1586 link1587 link1588 link1589 link1590 link1591 link1592 link1593 link1594 link1595 link1596 link1597 link1598 link1599 link1600 link1601 link1602 link1603 link1604 link1605 link1606 link1607 link1608 link1609 link1610 link1611 link1612 link1613 link1614 link1615 link1616 link1617 link1618 link1619 link1620 link1621 link1622 link1623 link1624 link1625 link1626 link1627 link1628 link1629 link1630 link1631 link1632 link1633 link1634 link1635 link1636 link1637 link1638 link1639 link1640 link1641 link1642 link1643 link1644 link1645 link1646 link1647 link1648 link1649 link1650 link1651 link1652 link1653 link1654 link1655 link1656 link1657 link1658 link1659 link1660 link1661 link1662 link1663 link1664 link1665 link1666 link1667 link1668 link1669 link1670 link1671 link1672 link1673 link1674 link1675 link1676 link1677 link1678 link1679 link1680 link1681 link1682 link1683 link1684 link1685 link1686 link1687 link1688 link1689 link1690 link1691 link1692 link1693 link1694 link1695 link1696 link1697 link1698 link1699 link1700 link1701 link1702 link1703

Форум — Ответы     (  К темам )
 ?  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 определены но не реализованы.