VBNet - Форум - Встроенные ф-ции vs API

Вопрос: Встроенные ф-ции vs API Добавлено: 02.06.05 02:02

Автор вопроса: ZagZag | ICQ: 295002202

Я уже года два на этом форуме... наблюдаю, учусь.
Так как я в последние полгода стараюсь изучать ассемблер и BP, то могу
заверить: API гораздо производительнее чем встроенные в VB ф-ции, но,
наверное, половина форумлян со мной не согласится. (Это вызвано, я думаю, по
большей мере малым опытом работы в VB)
Мне хотелось бы как-нибудь доказать производительность API...
Бета-тест мне делать покачто влом (а точнее я не могу подобрать более-менее
равных кандидатов от API и встроенных ф-ций), но если тему поддержат - можно
забабахать...

Еще в догонку: API также лучше чем контролы, которые вы используете
(CommonDialog, WinSock...)
А лучше они тем, что на эти контролы ругается даже WinXP без установленного
VB, т. ч. приходится их таскать вместе с программой.

Единственный аргумент ЗА контролы и встроенные ф-ции - они проще в освоении.

Топик посвящается тем, кто за рулем VB недавно.

PS
О я речь двинул! Я вообще сам частенько использую всякие там Open
strFileName For Binary Access..., но только потому что НЕ ИСКАЛ
подходящей замены... (аж стыдно)
Но всеж может вы и меня сможете образумит... попробуйте доказать что API
хуже :)

PPS
Пока это дело набирал нашел примерчик сравнения - поиск файла по маске.
Что может быть быстрее чем FindFirstFile? :)

Ответить

Ответы Всего ответов: 17

Номер ответа: 1 Автор ответа: GSerg Вопросов: 0 Ответов: 1876	Профиль \| \| #1	Добавлено: 02.06.05 05:15
	Касаемо быстроты API. Америку открыл, открыл, респект Касаемо контролов. Всегда и везде нужно таскать за собой используемые контролы, независимо ни от языка, на котором они написаны, ни от языка, который их использует. RTFM! Касаемо всяких там Open strFileName For Binary Access. Ты думаешь, скорость доступа к диску возрастёт, открой ты их через CreateFile? Или тебя волнует именно скорость самого процесса открытия? Ответить

Номер ответа: 2 Автор ответа: ZagZag ICQ: 295002202 Вопросов: 87 Ответов: 1684	Профиль \| \| #2	Добавлено: 02.06.05 05:29
	Всегда и везде нужно таскать за собой используемые контролы, независимо ни от языка, на котором они написаны, ни от языка, который их использует ИМХО, тут ты не прав. Моя экзеха с CommonControl на голой WinXP не пошла, а такая же в диалогом на АПИ заработала! Про Open File: Я думаю что кернеловские АПИ по-любому быстрее, но вот как их юзать (тот же CreateFile). Перешерстил API-Guide подходящего там не нашел Ответить

Номер ответа: 3 Автор ответа: Morpheus Вопросов: 224 Ответов: 3777	Web-сайт: xury.zx6.ru Профиль \| \| #3	Добавлено: 02.06.05 07:51
	Стандартны функции по полной от*ют, ну то есть "отдыхают" короче по сравнению с АПИ. Приложения на апи самые быстрые, мощные и лёгкие (правда они так же самые дорогие и "труднонаписуемые" по сравнению с испольщованием комерческих компонентов). Поэтому апи щас везде и пихают. я юзаю их оч давно, но изучать начал недавно... Я думаю что кернеловские АПИ по-любому быстрее Ну у меня Sleep вообще тормозит и всю прогу подвешивает ))))))))) Ответить

Номер ответа: 4 Автор ответа: GSerg Вопросов: 0 Ответов: 1876	Профиль \| \| #4	Добавлено: 02.06.05 07:56
	ИМХО, тут ты не прав. Моя экзеха с CommonControl на голой WinXP не пошла, а такая же в диалогом на АПИ заработала! ИМХО, ты невнимательно прочитал то, что я написал. Про Open File: Я думаю что кернеловские АПИ по-любому быстрее А я не думаю. Потому что в итоге всё равно всё сводится к ним. И Open File в итоге вызывает CreateFile. Причём наличие дополнительных затрат на вызов - не факт, потому что Open - это не функция-обёртка, а конструкция языка (как If, например). И в данном случае промежуточная стадия (затраты на вызов) несоизмеримо меньше затрат на работу. А работа идёт одним и тем же способом. Ответить

Номер ответа: 5 Автор ответа: GSerg Вопросов: 0 Ответов: 1876	Профиль \| \| #5	Добавлено: 02.06.05 08:03
	Стандартны функции по полной от*ют, ну то есть "отдыхают" короче по сравнению с АПИ. Ты функцию Left$ тоже через API объявляешь? Ответить

Номер ответа: 6 Автор ответа: sne Разработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445	Web-сайт: hw.t-k.ru Профиль \| \| #6	Добавлено: 02.06.05 10:00
	Все без исключения строковые функции что передают строку и туда и обратно, работают медленнее. Len vs lstrlen - в первом случае передается BSTR строка, а StrPtr - 4h - это ее длинна... Во втором же случае, BSTR строка приводится к виду обычной ANSI, и начинается посимвольное сравнение с нулем... Mid - Даже если ты реализуешь что-то подобное в dll, ты сможешь убедиться что стандартный Mid$ пошустрее будет... Снова время на преобразование строк + установка обработчика ошибки на перед первым вызовом АПИ... и т.д. ЗЫ FindNextFile - не стоит того чтобы на нем писать, обычно скорость винта много медленней... ЗЗЫ Работа с файлами по ср-вам CreateFile/OpenFile так же не будет отличаться существенной производительностью, по сравнению с VB'шным бинарным доступом. Вывод: API конено хорошо, для VB'шника это практически спасение но знать меру надо везде и во всем... Ибо реализовывать гроадный кодв котором нет смысла - расточительство... Ответить

Номер ответа: 7 Автор ответа: sne Разработчик Offline Client ICQ: 233286456 Вопросов: 34 Ответов: 5445	Web-сайт: hw.t-k.ru Профиль \| \| #7	Добавлено: 02.06.05 10:01
	Ну у меня Sleep вообще тормозит и всю прогу подвешивает ))))))))) LOL Ответить

Номер ответа: 8 Автор ответа: LamerOnLine ICQ: 334781088 Вопросов: 108 Ответов: 2822	Профиль \| \| #8	Добавлено: 02.06.05 10:43
	Я тоже считаю что АПИ имеет смысл использовать либо для расширения функциональных возможностей (типа функций коих нет в ВБ), либо для того чтобы не таскать уйму контролов, что, в сущности, одно и то же. По скорости выигрыш получить весьма сложно. Опять же, нужно преобразовывать типы данных, кидать их в стек при вызове, часто затем приходится копировать блоки памяти и т.п. То есть, кода раз в 50-70 больше будет, а разность производительности - проценты, и те заметны лишь в циклах. Ну а про CreateFile, пожалуй, актуально лишь если у тебя загружен Ramdrive.sys Вообще, ИМХО, нет нужды изобретать велосипед, все ВБ функции сводятся к тем же АПИ, и написаны они не Васей Пупкиным на VB, а опытними программерами на С. Ну а если писать на одних АПИ - зачем тогда VB нужен? Переходи на С++. Ответить

Номер ответа: 9 Автор ответа: *CyRax* Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229	Web-сайт: basicproduction.nm.ru Профиль \| \| #9	Добавлено: 02.06.05 11:16
	BP это что? Borland Pascal? Или ты имел ввиду PB? Поддержка API несомненно положительная характеристика VB. Кто-то воспринимает её как должное, но например в 1C такого вообще нет. Встроенные VB-функции устроены довольно профессионально и при умелом их использовании можно получить вполне неплохие результаты. В то же время рациональное комбинирование встроенных функций с системными API позволяет также получить довольно высокую скорость работы приложения. Но концептуальные (согласно концепциям Микрософта) ограничения у языка всё же есть, а это, в свою очередь, накладывает некоторые неудобства при работе с API. Так что вопрос что лучше здесь довольно спорный. Если бы язык в полной мере поддерживал системное программирование (как например PowerBasic), тогда можно было бы говорить о рациональности использования того или иного способа, а так, максимум - это комбинированный. Ответить

Номер ответа: 10 Автор ответа: iLLyuzor ICQ: 223685087 Вопросов: 9 Ответов: 77	Профиль \| \| #10	Добавлено: 02.06.05 12:00
	А я вообще не понимаю смысла использования API только для того чтобы не таскать контролы вместе с программой. Места жалко или тащить тяжело? Так не в руках же их таскаешь, для этого инсталятор есть. Зато используешь красивые, функциональные средства, с хорошей документацией и примерами. Ответить

Номер ответа: 11 Автор ответа: Sur ICQ: 1249088 Вопросов: 10 Ответов: 304	Web-сайт: sur.hotbox.ru/ Профиль \| \| #11	Добавлено: 02.06.05 18:12
	1. API быстрее встроенных в язык функций по определению. 2. API расширяет возможности языка. 3. Если не нужно первые 2 пункта - не надо юзать API ЗЫ странная поднята тема: > попробуйте доказать что API хуже Вот это задача! Ответить

Номер ответа: 12 Автор ответа: *CyRax* Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229	Web-сайт: basicproduction.nm.ru Профиль \| \| #12	Добавлено: 02.06.05 18:18
	> попробуйте доказать что API хуже Не хуже, а невполне удобны в VB, который ориентирован большей частью на прикладное программирование. Ответить

Номер ответа: 13 Автор ответа: HACKER Разработчик Offline Client Вопросов: 236 Ответов: 8362	Профиль \| \| #13	Добавлено: 02.06.05 19:09
	гля вы гоните! можите назвать меня ленивым, но мне влом лезть в айпи вьвер, искать там ту блин функцию, копипестить это в вб, читать там чё ей передавать итп... нахрн нужно? чтоб выграть милисикунды? масксимум 1 сек. Другое дело если нет нужной встроеной функции... Ну а что касается айпи и контролов - спорный вопрос. В большенстве моих случаев, в принципе всёравно сколько будет весить прога, но есть и исключения... Возьми к примеру элементарный shell напиши для связи двух компов, виншок прицепиш то + ~600 КБ, а если это типа троян, прога которая должна быть маленькая... то контрол тут никатит... Да и вообще использовать айпи я считаю лучше, тогда когда есть хороший движёк. Вот к примеру нафиг вам виншок, если есть таже Тяга (DaSharm её писал), ей что сложнее чем виншоком пользоваться - нет! За то никаких проблем с большим весом проги, регестрации виншока в реестре (если голая тачка) итп... Короче комбинирование встроеных функций и айпи! Ответить

Номер ответа: 14 Автор ответа: ZagZag ICQ: 295002202 Вопросов: 87 Ответов: 1684	Профиль \| \| #14	Добавлено: 03.06.05 07:26
	GSerg, да я невнимательно прочел... Не стандартные контролы по-любому прийдется таскать, но от таскания стандартных можно себя избавить. Про Open File... я и говорю - не знаю как это на АПИ написать, знал бы - наверное писал Как строку АПИ копировать? lstrcpyn или MoveMemory - как параметры передавать. (На асме lstrcpyn работает, а на VB чето не так передавать надо) Ответить

Номер ответа: 15 Автор ответа: GSerg Вопросов: 0 Ответов: 1876	Профиль \| \| #15	Добавлено: 03.06.05 12:03
	Стандартный, хе, "контрол" в VB один, и называется он msvbvm60. Избавь себя сначала от таскания его. А если не сможешь, юзай всё, что в нём есть, и не страдай фигнёй. Ответить

Страница: 1 | 2 |