Грамотное использование inc файлов

[Klod]

Всем привет! У меня небольшой вопрос про include файлы, в которых должно содержаться определение нужных функций. Заключается он в следующем.
Когда для приложения нужно определять функции, мы дабы не захламлять код записываем их в .inc файлы. Но в masm32 уже есть файлы kernel32.inc, user32.inc и windows.inc. В них целая куча объявляемых функций. Но мне нужны лишь 2-3 из них. И есть возможность писать те же inc файлы, но с теми функциями, которые мне нужны.
Возникает вопрос: если использовать стандартные (из набора masm32) inc файлы(с целой кучей ненужных объявлений функций), а не написанные мной лично (в который пара-тройка функций объявлено) будет ли разница в быстродействии моего кода?

[Ezhik Kihze]

Нет. В инках только прототипы, линкер вставить только используемые.

[DiemonStar]

Возникает вопрос: если использовать стандартные (из набора masm32) inc файлы(с целой кучей ненужных объявлений функций), а не написанные мной лично (в который пара-тройка функций объявлено) будет ли разница в быстродействии моего кода?

А вы вообще вдумайтесь в вопрос. Функции на исполнение не вызываются, алгоритм по-сути тот же, так откуда взяться замедлению быстродействия? Даже если бы компилятор-линкер не отсекали неиспользуемые функции, то максимум что они делали бы - спокойно лежали в памяти и немного ее захламляли. Т.е. изменения не в быстродействии, а в объеме исполняемого кода и, как следствие, некоторая задержка при запуске программы из-за большего объема загружаемого файла.

[Ezhik Kihze]

И в объеме не будет...

[DiemonStar]

Сообщение от Ezhik Kihze

И в объеме не будет...

Да я вас понял Это просто попытка помочь человеку думать логично...

[Mikl___]

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

.386
.model flat
include windows.inc
include kernel32.inc
include user32.inc
includelib user32.lib
includelib kernel32.lib
 
.data
MsgCaption      db "Iczelion's tutorial #2",0
MsgBoxText      db "Win32 Assembly is Great!",0
 
.code
start:
    invoke MessageBox, NULL,addr MsgBoxText, addr MsgCaption, MB_OK
    invoke ExitProcess,NULL
end start

заглядываем в ЕХЕ-файл через hiew32

.00400230: 6A00          ; push MB_OK
.00400232: 6800304000    ; push offset MsgCaption
.00400237: 6819304000    ; push offset MsgBoxText
.0040023C: 6A00          ; push 0
.0040023E: E807000000    ; call [40024A];invoke MessageBox,NULL,addr MsgBoxText,addr MsgCaption,MB_OK
.00400243: 6A00          ; push 0
.00400245: E806000000    ; call [400250];invoke ExitProcess,NULL
.0040024A: FF250820400000; jmp MessageBoxA
.00400250: FF250020400000; jmp ExitProcess

вместо того, чтобы напрямую вызывать MessageBoxA и ExitProcess мы сперва вызываем "подпрограммы" по адресам 40024A и 400250 с которых совершаем прыжки на настоящие MessageBoxA и ExitProcess, такого бы не было если бы не использовались inc-файлы

.386
.model flat
include windows.inc
includelib user32.lib
includelib kernel32.lib
extern _imp__MessageBoxA@16:dword
extern _imp__ExitProcess@4:dword
.code
start:  push MB_OK
    push offset MsgCaption
    push offset MsgBoxText
    push NULL
    call _imp__MessageBoxA@16
    push NULL
    call _imp__ExitProcess@4
.data
MsgCaption      db "Iczelion's tutorial #2",0
MsgBoxText      db "Win32 Assembly is Great!",0
end start

[Ezhik Kihze]

Только вот к инкам это не имеет отношение... Это компилятор работает.

[Mikl___]

Ezhik Kihze,
хорошо, пусть компилятор... Но какой нужно указать ключ компилятору, чтобы не было бы этих лишних джампов? Это как раз следствие "инвокабельности" вызова ВинАПИ-функций
при сборке программы с включением

extern _imp__MessageBoxA@16:dword
extern _imp__ExitProcess@4:dword

и отсутствием строк

include kernel32.inc
include user32.inc

лишние джампы исчезнут

[f.hump]

Опять таки, ни какой разницы нет, используете вы inc или нет, для всех вызовов из сторонних длл. Как ни пиши такие вызовы всегда непрямые и проходят через jump table.

лишних прыжков нет - они все нужные.


так что, как ни крути, ничего там не исчезнет.

[Mikl___]

f.hump

Как ни пиши такие вызовы всегда непрямые и проходят через jump table.

Да, ну? А проверить? Пример я дал, hiew32, надеюсь, найти не сложно, покрутите, попробуйте...