Отправлено: 17.11.23 20:41. Заголовок: gc3 или gc1

Начитался тут :)
Остановился на gc1
Тема тут
Кто чего думает по этому поводу ?

 Отправлено: 17.11.23 20:51. Заголовок: Знаешь, по-моему, го..

Знаешь, по-моему, гораздо важнее, на каком железе работаем. Эта тема примерно та же, что и прошивка авто без тюнинга мотора/трансмиссии. Вроде лучше, но это - не точно)) Это - имхо

 Отправлено: 17.11.23 20:55. Заголовок: PSP Та да нужно еще..

PSP
Та да нужно еще потестить )

 Отправлено: 17.11.23 22:06. Заголовок: Быстрый тест сборки ..

Быстрый тест сборки и работы моего приложения
gc0 и gc1 размер EXE примерно одинаков +- 1 кило , в работе одинаково
gc3 собирается намного дольше раза в 3 дольше и размер EXE примерно на 25 % больше
даже если его жать UPX , но визуально работает намного шустрее , но это не точно
Буду конкретные простые тесты делать с замером времени , потому как на глаз это не то ))

 Отправлено: 18.11.23 10:37. Заголовок: Интересно...))..

Ну, так-то да. Даже теоретически должно работать быстрее. "Лишнее" звено отсутствует. Так что интересно...))

 Отправлено: 18.11.23 15:23. Заголовок: Потестил и продолжен..

Потестил и продолжение темы там глянул , фигня это всё с gc3
Единственно что , обнаружил что если UPX скормить опцию --lzma ,
то EXE ощутимо худеет ))

 Отправлено: 18.11.23 16:05. Заголовок: Чтобы было понятно, ..

Чтобы было понятно, что это вообще такое:

Классический клиппер, его PLANKTON, или его наследник харбор с его виртуальной машиной работает так:

HB_FUNC_STATIC( SPD_OUT )
{
static const HB_BYTE pcode[] =
{
HB_P_FRAME, 1, 6,
HB_P_SFRAME, 153, 0,
HB_P_MODULENAME,
's', 'p', 'e', 'e', 'd', 't', 's', 't', '.', 'p', 'r', 'g', ':', 'S', 'P', 'D', '_', 'O', 'U', 'T', 0,
HB_P_LOCALNAME, 1, 0,
'P', '1', 0,
HB_P_LOCALNAME, 2, 0,
'P', '2', 0,
HB_P_LOCALNAME, 3, 0,
'P', '3', 0,
HB_P_LOCALNAME, 4, 0,
'P', '4', 0,
HB_P_LOCALNAME, 5, 0,
'P', '5', 0,
HB_P_LOCALNAME, 6, 0,
'P', '6', 0,
HB_P_LINE, 229, 0,
HB_P_LOCALNAME, 7, 0,
'N', 'P', 'C', 'O', 'U', 'N', 'T', 0,
HB_P_PUSHFUNCSYM, 14, 0,
HB_P_FUNCTIONSHORT, 0,

это пи-код

и в конце функции пи-код передается на выполнение виртуальной машине:

HB_P_ENDPROC
};

hb_vmExecute( pcode, symbols );
}

это -gc1

теперь разбираем -gc3. Это не интерпретатор, а нативный c-код, который выглядит как ниже. Вместо пи-кода в данных идет вызов функции, смотрите:

HB_FUNC_STATIC( SPD_OUT )
{
HB_BOOL fValue;
do {
hb_xvmFrame( 1, 6 );
hb_xvmSFrame( symbols + 153 );
hb_xvmModuleName( "speedtst.prg:SPD_OUT" );
hb_xvmLocalName( 1, "P1" );
hb_xvmLocalName( 2, "P2" );
hb_xvmLocalName( 3, "P3" );
hb_xvmLocalName( 4, "P4" );
hb_xvmLocalName( 5, "P5" );
hb_xvmLocalName( 6, "P6" );
hb_xvmSetLine( 229 );
hb_xvmLocalName( 7, "NPCOUNT" );
hb_xvmPushFuncSymbol( symbols + 14 );
if( hb_xvmFunction( 0 ) ) break;
hb_xvmPopLocal( 7 );
hb_xvmSetLine( 231 );
hb_xvmPushStatic( 1 );
if( hb_xvmPopLogical( &fValue ) ) break;
if( ! fValue )
goto lab00007;
hb_xvmSetLine( 233 );
hb_xvmPushLocal( 7 );

Нативный код выполняется быстрее, но и места занимает больше. Насколько быстрее - смотрим speedtst.prg

виртуальная машина -gc1 - 25 сек, размер 930к, нативный код - 22 сек, размер 970к

Я смутно помню, как лет 10-15 назад я решал для себя этот вопрос, и тогда решил - овчинка не стоит выделки. Вроде тогда разница в быстродействии была лучше, но и компы были другие
Кстати, тогда еще копался с виртуальной машиной на предмет ее оптимизации, но ни к чему это не привело

 Отправлено: 18.11.23 16:16. Заголовок: Pasha Спасибо !..

Pasha
Спасибо !

 Отправлено: 19.11.23 10:17. Заголовок: Значит всё-таки фигн..

Значит всё-таки фигня...)) Железо - наше всё))