STL и MFC: выход за границы модуля и производительность

[lapulya]

ладно, забейте... я понял не достучусь я до вас... бум считать что я нажрался и напорол всякой чуши (вы думаете это я для себя стараюсь)))  или это я типа круть свою показать хочу... так мне это не надо... то что я крут не в меру, так я это и так знаю, а стараюсь я не для себя, мне не надо, я уж лет восемь как не пишу.... это как у Филатова... третий день ей ей не вру, саблю... в руки не беру...)

[lapulya]

Джон, я так (уже без надежды)... чисто обратить внимание, что речь шла о проблемах при передаче объекта через границу модуля и уже там, в другом модуле, переаллоцирование памяти (в качестве примера приводилась передача sdt::string и описание возникающих при этом проблем и описанием того откуда они бесутся), а так же о том, что нехорошо менять контент сонстантного буфера, особенно предоставленного чужим для тебя кодом/библиотекой. Я покрайней мере дисутировал об этом

В чем твоя мммм твой аргумет, когда ты привел пример

Код:

DWORD dwSize = 0;
кто-то_неважно_кто->GetData(NULL, &dwSize);
*p = new тип_данных[dwSize];
кто-то_неважно_кто->GetData(p, &dwSize);
...

delete [] p;

я так и не понял, т.е. никто не говорил что так делать нельзя когда дело касается одного модуля, если найдешь у МЕНЯ такую фразу в дискусии или хотябы намек на нее я признаю себя полным мутантом (может у меня с логикой проблемы... но я этого ранее не наблюдал)

[Алексей++]

могу сказать что для многих приложений он слишком громоздкий, медленный и отжирает слишком много памяти

не замечал Всё летает, экзешник маааленький, озу занято ровно столько, сколько весит программа+сколько я выделил памяти на переменные, не больше

вот для офисных приложений его скорость с большим запасом хватает, поэтому ты и не ользуешься чистым АПИ, поскольку тебе писать программу используя MFC удобнее и быстрее

опять придумываешь то, чего нет Я не пишу офисных, у меня скорость очень даже критична - мы занимаемся охранными системами
АПИ активно не  пользуюсь, потому что удобнее MFC, но вместе с тем легко и без зазрения совести использую АПИ там, где не реализована MFC или просто по велению желания

Ну а есть приложения где он не применим

примеры обязательны

lapulya, да никто не просит до нас достучаться Всё нормально , но меня ты не переубедил (а в чём - фиг знает, ни в чём )

[lapulya]

Леха,

не замечал  Всё летает...

Ну и понятно, заметить можно на приложениях, которым нужна мега скорость (ну игры например, ОС (хотя это ммм не очень корректный наверное пример, но игры очень показательный) и т.д.

не замечал  ... экзешник маааленький...

Еслиб ты все тоже самое написал на чистом АПИ ты бы понял о чем речь (опять же все относительно, для ммм примера создай приложение в котором просто отображается окно на АПИ и с помощью MFC и сравни)

не замечал  Всё летает...озу занято ровно столько, сколько весит программа+сколько я выделил памяти на переменные, не больше

)))) так ровно так будет даже если использовать самую не эффективнуб библиотеку (естественно памяти отжирается ровно столько, сколько ты сказал ))) )

Цитировать

Ну а есть приложения где он не применим

примеры обязательны

На вскидку игры

опять придумываешь то, чего нет  Я не пишу офисных, у меня скорость очень даже критична - мы занимаемся охранными системами
АПИ активно не  пользуюсь, потому что удобнее MFC, но вместе с тем легко и без зазрения совести использую АПИ там, где не реализована MFC или просто по велению желания

Я никогда ничего не придумываю, я предполагаю, видимо охранная система не критична к скорости (это опять предположение), мне как стороннему наблюдателю не очевидно, где там скорость нужна (сработает она сек. позже или раньше, но роизнаю что могу ошибаться). Кстати вопрос, то место в системе где важна скорость, выполняется на тойже машине и в рамках того же процесса, что и GUI? Ответ нет, говорит о том, что не мы говорим о проблеме узкого места (я допускаю что оно есть, но не тут). Если ответ да, то ммм могу порекомендовать переписать какую-то часть (отдельный модуль) на АПИ (полностью) и замерить скорость и память, а потом потребовать у руководства премии и повышения, поскольку этот модуль будет работать тем быстрее, чем больше в нем было кода из MFC и занимать тем меньше мапяти, чем больше объектов MFC в нем создавалось. (когда я говорю про память я имею ввиду И объем экзешника И объем отжираемого прогой ОЗУ)

[Джон]

я так и не понял

На самом деле всё очень просто:

кто-то_неважно_кто->

Вот этот самый "неважно кто" может быть чем угодно - в данном случае - другим модулем. Именно он должен мне сообщить какого размера буфер необходим для данных, чтобы Я его создал, а потом опять же Я его удалил. Кстати такую конструкцию желательно использовать не только при получении данных из другого модуля. Очень полезно ВСЕГДА вместе с указателем на буфер передавать и размер этого буфера. Конечно подразумевается, что ответная сторона должна уметь правильно использовать эти данные.

зы Ну и тоже, к слову - про MFC, STL и пр. это уж совсем ни к селу ни к городу. Эта проблема не зависит от неких врапперных библиотек. Чем передача скажем массива типа int отличается? Если ты видишь, что другой не прав, то чётко сформулируй проблему и укажи на неё, а ты подхватил MFC, STL, new, malloc, скоростная реализация, пургу про debugger понёс... в итоге столько лишних килобайт спихнул... А сформулировать проблему можно в нескольких словах. Чем меньше слов, тем меньше комбинаций. Тогда и дисскутировать проще - всё чётко и ясно.

[lapulya]

Джон, я все описал очень четко. Если я хоть где-то не четко или нелогично что-то написал или привел некорректный пример, то приведи любой пример из моей фразы? Вот где у меня есть высказывание, которое не следует из моего предыдущего поста или поста моего собеседника - повторяю ХОТЬ ОДИН пример приведи, и я признаю, что я был неправ.

[lapulya]

Джон, ты пишишь

Вот этот самый "неважно кто" может быть чем угодно - в данном случае - другим модулем. Именно он должен мне сообщить какого размера буфер необходим для данных, чтобы Я его создал, а потом опять же Я его удалил. Кстати такую конструкцию желательно использовать не только при получении данных из другого модуля. Очень полезно ВСЕГДА вместе с указателем на буфер передавать и размер этого буфера. Конечно подразумевается, что ответная сторона должна уметь правильно использовать эти данные.

Вот ты мне объясни к чему ты это написал (вотт где логика в твоих утверждениях)? Кто-то спрашивал можно ли передать данные из модуля в модуль? Или может кто-то спрашивал как именно можно передать данные из модуля в модуль? Можно цитату где есть хоть намек на это?

Из твоего поста без разьяснений тех, что в твоем последнем посте, наверное я тупой, но мне было не понятно, к чему это написано... Видимо я просто мыслил именно в контексте обсуждаемых вопросов и не смог привязать к ним твой совет и твой код.

далее

Ну и тоже, к слову - про MFC, STL и пр. это уж совсем ни к селу ни к городу. Эта проблема не зависит от неких врапперных библиотек. Чем передача скажем массива типа int отличается? Если ты видишь, что другой не прав, то чётко сформулируй проблему и укажи на неё, а ты подхватил MFC, STL, new, malloc, скоростная реализация, пургу про debugger понёс... в итоге столько лишних килобайт спихнул... А сформулировать проблему можно в нескольких словах. Чем меньше слов, тем меньше комбинаций. Тогда и дисскутировать проще - всё чётко и ясно.

А stl и MFC тут как раз причем! Поскольку речь шла не о буфере как таковом - типа области памяти для передачии ее через границу модуля (это как раз то, что ты имел ввиду в своем посте и твоем примере), а о буфере инкапсулированном в std::string и CString, другими словами речь шла про передачу объектов, которые располагаются в памяли и импользуются в разных модулях и о проблемах перераспределении памяти во время "блуждания" этих объектов между модулями. Вот речь то о чем шла! И ВСЕ мои посты логичны обоснованы и точны, а также четко следуют из предыдущих (а вот твои нет).

[Алексей++]

lapulya, игры тоже на си++ часто пишут. Летает же Платы - ускорители рулят , аудио, видео, физические даже есть

Еслиб ты все тоже самое написал на чистом АПИ ты бы понял о чем речь (опять же все относительно, для ммм примера создай приложение в котором просто отображается окно на АПИ и с помощью MFC и сравни)

по размеру - не думаю, что намного будет разница, что есть 64 килобайта сегодня ? )

)))) так ровно так будет даже если использовать самую не эффективнуб библиотеку (естественно памяти отжирается ровно столько, сколько ты сказал )))

так будет всегда и везде

На вскидку игры

пишут, я даже не сомневаюсь в этом.

Охранная программа очень активно работает с ресурсами - инфы по радиоканалу приходит море, всё это надо складывать в базу и показывать операторам на сервере и 10-20 клиентах. Секунды решают всё: если где то нажали тревожную кнопку, опоздание на 5 секунд может обернуться , в общем то, бедой. Программа работает месяцами без выключения , параллельно на компе запускаются и работают другие программы - нормально работают По структуре в программе всего один дополнительный поток, кроме основного процесса, поток читает данные с порта

зы Джон прав, при чём тут MFC, не MFC ? ) Тормозов в MFC не больше, чем в АПИ , всё зависит от кривизны рук )

[lapulya]

Алексей1153++,

игры тоже на си++ часто пишут. Летает же  Платы - ускорители рулят , аудио, видео, физические даже есть

ЭЭЭЭ не знаю что сказать... я бы сказал так - обычно (а не часто) их пишут на с++... Может ты хотел написать "игры тоже с использованием MFC часто пишут." ну скажем так я знаю всего пару игр (а игр вообще я знаю очень много) которые были написаны с использованием MFC (я говорю про саму игру, а не например редактор карт или миссий) и все они пошаговые стратегии, шахматы например, ну или на вскидку варлорд2 и 3, но их не много и им не нужна высокая производительность.

по размеру - не думаю, что намного будет разница, что есть 64 килобайта сегодня ? )

А ты смотри не абсолютную а относительную разницу (типа не на сколько, а во сколько)

так будет всегда и везде

ну дык я об этом и написал (сама прога включая любые библиотеки ничего не выделяет))) если ей программер не укажет)

опоздание на 5 секунд может обернуться , в общем то, бедой.

я так понял что может обернуться, а может и нет... в любом случае 5 секунд это сумашедшее время для систем реального времени (не знаю инграешь ли ты в игры, но ты только представь как удобно играть в реал тайм стратегию, аркаду, шутер, авиа/авто симулятор или онлайн игру типа WoW с задержкой в 5 секунд, если не играл, то я могу сказать - играть с подобной задержкой не трудно, а просто невозможно, ну или точнее возиможно, но всегда проиграешь)))) )

зы Джон прав, при чём тут MFC, не MFC ? ) Тормозов в MFC не больше, чем в АПИ , всё зависит от кривизны рук )

Я не хочу сказать что MFC полный отстой, скорее наоборот, в опытных руках это достаточно хороший (для определенного круга задачь, как впрочем любая библиотека) инструмент существенно увеличивающий скорость разработки приложения с нуля, но по скорости чистому АПИ он уступает и сильно (я ж говорю просто выведи окнои и замерий время), когда я говорю сильно это не 5 секунд и не одна, скорость как и память, лучше мерить в относительных единицах, а не в абсолютных, тогда будет видно что ммм ты получаешь используя АПИ (иначе и использовать его грех, если от него никакой пользы нет).

Выскажу личное мнение (прошу сильно не пинать) - мне MFC не нравится ия ее не использую, по сути у меня своя MFC (обертка над АПИ), я ее давно написал и от проета к проекту улучшал, что при этом имел...
положительные моменты - гораздо большую гибкость, скорость и экономию в ресурсах, а также архитектуру, которая казалась оптимальной
отрицательные моменты - достаточно много времени на проектирование, разработку и отладку (как следствие низкая скорость разработки до выхода в свет первой ммм версии, а далее как по накатанному, но местами при развитии также были затыки, но не часто и они были не большими) + необходимость ее развивать + немного времени уходило на поддержку нескольких версий библиотеки (правда реально очень мало, но всетаки) которые использовались разными приложениями (это естественно, этож не коммерческая библиотека и как и любая не коммерсческая она развивалась и хочешь или нет, некоторые решения в интерфейсах были не очень удачными. Ну а следовательно: или допилка клиентского кода и использование единой версии бибилиотеки для всех кдиентов, или код клиента константен и поддержка нескольких библиотек. Я не сторонних крайних мер, поэтому делал то так, то подругому), а так же из недостатков следует отметить трудности с передачей ее другим программистам (документации я не писал, все что было - это комментарии в особо сложных участках кода + выгрузка в розу диаграммы классов в разрезе модулей)

[Алексей++]

lapulya, я сказал, что хотел сказать Производительность у MFC хорошая, если это не так - приведи конкретные примеры или вообще не говори об этом

я так понял что может обернуться, а может и нет... в любом случае 5 секунд это сумашедшее время для систем реального времени (не знаю инграешь ли ты в игры, но ты только представь как удобно играть в реал тайм стратегию, аркаду, шутер, авиа/авто симулятор или онлайн игру типа WoW с задержкой в 5 секунд, если не играл, то я могу сказать - играть с подобной задержкой не трудно, а просто невозможно, ну или точнее возиможно, но всегда проиграешь)))) )

люди платят за безопасность, они знают, что ОЧЕНЬ скоро после нажатия приедет наряд с автоматами Им "может да, может нет" не нужно
Скорость реакции реал-таймовых игр зависит от скорости соединения, так как процессор намного быстрее скорости обмена. О чём тут говорить ? при чём тут язык вообще ?

но по скорости чистому АПИ он уступает и сильно (я ж говорю просто выведи окнои и замерий время),

да ничего никто не уступает Сам то хоть замерь, где же должны быть тормоза - сообщения передаются так же, код в циклах работает так же, потоки такие же - где ?

Выскажу личное мнение (прошу сильно не пинать) - мне MFC не нравится ия ее не использую, по сути у меня своя MFC (обертка над АПИ), я ее давно написал и от проета к проекту улучшал, что при этом имел...

я уважаю твоё мнение, но у меня есть своё. И у меня затыков нету , раньше были , сейчас уже нету Согласись, если бы программы у меня плохо или медленно работали - меня бы уволили просто

---------
зы а в остальном: если ты поставил цель просто спорить, то не переспоришь ) Вот когда веские аргументы станешь приводить, тогда и посмотрим А так - хоть до посинения

[lapulya]

Алексей1153++,

lapulya, я сказал, что хотел сказать  Производительность у MFC хорошая, если это не так - приведи конкретные примеры или вообще не говори об этом

Если говоря про пример ты имел ввиду - докажи, что использование MFC в играх тормозит их, то не буду (это аксиома и в доказательствах не нуждается, если я тебя именно в этом не убедил, точнее если ты в этом сомневаешься или просто считаешь что это утверждение не верно, спорить и даже дискутировать не будет просто расстаемся каждый со своим мнением)

Скорость реакции реал-таймовых игр зависит от скорости соединения, так как процессор намного быстрее скорости обмена. О чём тут говорить ? при чём тут язык вообще ?

Первое - скорость реал тайм-игр от скорости соединения не зависят (они вообще без сети могут работать), от скорости соедингения может зависеть онлайн игры, но опять таки скорость соединения тут непричем, потому как пропускная способность канала в наши дни, не знаю как в Златоусте, но у меня в Москве гораздо (на несколько порядков) больше нежели необходима любой игре в которые я играл (включая WoW для определенности).
Второе - я про язык первым ничего не говорил (я только дал комментарий на твое "игры тоже на си++ часто пишут"), поэтому причем тут язык программирования это я у тебя спросить должен? С чего ты про него говорить стал?
В третьих - (еще раз повторю то, что написано выше) Если говоря про пример имел ввиду - докажи, что использование MFC в играх тормозит их, то не буду (это аксиома и в доказательствах не нуждается, если я тебя именно в этом не убедил, точнее если ты в этом сомневаешься или просто считаешь что это утверждение не верно, спорить и даже дискутировать не будет просто расстаемся каждый со своим мнением)

да ничего никто не уступает  Сам то хоть замерь, где же должны быть тормоза - сообщения передаются так же, код в циклах работает так же, потоки такие же - где ?

Ладно (тебе лень я понял ))) ), я сам эти две строчки напишу и вышлю результаты по скорости работы + оперативной памяти + памяти на диске (кстати )))))))))) MFC по умолчанию статически линкуется, да?)))) )

Согласись, если бы программы у меня плохо или медленно работали - меня бы уволили просто

Соглашусь с самим утверждением. Но из этого следует ровно следующее, результаты твоей работы устраивают работодателя, перефразирую - скорость работы программы, которую ты разрабатываешь достаточна для данного класса приложений. Не более того. Т.е. отсюда не следует что скорость MFC не уступает скорость АПИ и тем более,что использование MFC в играх (требующих высокой производительности) возможно.

Я не спорю, я дискутирую, причем если вещи очевидны или широко известны, то по ним не дискутирую ибо нет смысла (это просто спор ради спора), а вот если не совсем, то могу и пообсуждать.

[Алексей++]

это аксиома и в доказательствах не нуждается,

то есть ты признаёшь своё бессилие привести хорошие примеры ?

Первое - скорость реал тайм-игр от скорости соединения не зависят

я подумал, что ты говорил об игре по сети (локально никто 5 секунд не допустит задержку - это и так понятно)

MFC по умолчанию статически линкуется, да

да . Ну давай, напиши , подсчитай.

[lapulya]

Алексей1153++,

то есть ты признаёшь своё бессилие привести хорошие примеры ?

Да, ибо это именно тот момент, когда я считаю, что хочешь поспорить только ради спора.

я подумал, что ты говорил об игре по сети (локально никто 5 секунд не допустит задержку - это и так понятно)

Даже если говорить про игры по сети, то есть огромное количество игр (именно по сети) в которых задержка в 5 секунд невозможна (точнее неприемлена, при таких задержках проигрышь гарантирован), как пример WoW + все те игры что я перечислил ранее (но теперь рассмотреть вариант игры по сети. По ясню, подавляющее большинство игр позволяют играть как типа против компа - стендэлон, так и по сети, против(ну или за ))) ) людей)

да . Ну давай, напиши , подсчитай.

Ок напишу... Тока не гони...

[lapulya]

Напасал, итак (у меня виста, 2005 студия):
На диске
MFC - 276Кб
API - 56Кб

В памяти (тут сложновато, использую таск менеджер, другого не имею)
MFC
памяти - 9 756Кб, выделенной памяти (в чем отличие от предыдущего пораметра не знаю) - 2 236Кб
API
памяти - 8 028Кб (более чем на 1,5Мб меньше), выделенной памяти (в чем отличие от предыдущего пораметра не знаю) - 2 016Кб (более 200Кб)

Скорость выполнения
MFC - 195 тиков (в среднем по GetTickCount)
API - 157 тиков (в среднем по GetTickCount)

А я только одно окно вывел

[Алексей++]

во первых, не знаем чистоты эксперимента: какой проект, как построен, что делает?
-----------------
1) как видим, разницы практически нет ни в чём, немного больше озу - это ерунда, совсем мизерно больше экзешник - туфта (они НА столько и будут отличаться - dll то уже встроена и её размер не измениться, то есть будет 2Mb на API и 2Mb+220байт на MFC - если грубо.) Если это не так - доказывай
2) тики отличаются немного. Кстати: а)как мерял  ? b) почему значения близки к маленькой отметке шкалы ? Метрологию не учил ? Сколько измерений делал для получения среднего значения ?

[sss]

Алексей1153++, хватит дразнить человека. У меня давно случай был. Устраиваюсь я как-то на работу, сидит дядя и задает мне вопрос. Какой код работает быстрее - на ассемблере или delphi. Ну в общем аксиомный такой вопрос. И тут меня злость взяла. Я ему - без разницы. Один хер все упрется в сервисы системы и навык писателя. Ну и не взял он меня, а мне и лучше - как я теперь думаю . Это я к чему - хватит писями мериться....
Алексей1153++, вчера кстати был день метролога. Поздравляю 

[Алексей++]

sss,
да я не дразню Пусть человек, раз так рьяно доказывает ошибочное мнение, убедится, прав он или нет. Или я убедюсь. Неважно Просто потом нам знание об этом пригодится как ему, так и мне.

[Алексей++]

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

[Антон (LogRus)]

не знаю что за тест, но для меня явно мало данных о тесте.
лично мне нужно что бы тест шел минимум 1 минуту
при этом нужно получить данные о числе итераций и суммарном времени
о памяти хочется знать mem usage/VM Size - это из таскменеджера и virtual bytes/private bytes из монитора производительности.
и нет описания теста.

[lapulya]

LogRus, я ж написал что у меня виста, а ты про показатели из таск менеджера ХР, я в висте ничего серьезного не писал и что это за показате памяти не знаю (вообще их в висте 5 или 6 на процесс, все имеют разное значение), я ж это открыто написал, вот есть два показателя (из 6) чем один от другогоотличается - я не знаю))) - названия обоих привел.

О тестах
количество прогонов - 100 (это я о тиках), вопрос пушистого "почему значения близки к маленькой отметке шкалы " я не понял. Приеденное значение тиков это разница между количеством тиков в начале выполнения и сразу после UpdateData (после отрисовки окна), на самом деле разница еще польше (читай апи быстрее), паотому что объект app создается раньше того момента когда мы в мэйн попадаем. То что разница не вылика, так еще раз повторю, проги только окно создают и отрисовывают и все!!! пишите проги больше, соответственно и абсолютная разница будет расти, а вот относительная около 20%, помоему это существенно и эта тенденция только увеличится (не забываем про контролы и т.д.) - на мой всзляд этого достаточно, чтобы признать что апи быстрее (конечно не в разы, но я об этом и раньше говорил, я даже сомневаюсь, что при большом размере программы этот показатель достигнет 2... ну т.е. апи не будет работать в 2 раза быстрее, но в 1,5 легко). Леха как я говорил, в приложениях не критичных к скорости (памяти и т.д.) никто и никогда разницы на глаз не заметит.

Ну а про проги, тут по максимуму в MFC обрезано, архитектура документ - вид убрана, подержки сторонних библиотек и технологий (типа бд и активХ), убран тул бар, короче убрано все (т.е. приложения по функционалу одинаковы - голое окно и меню)

[lapulya]

Кстати, еслибы это окно было диалоговым (с контролами и побрякушками) разница былабы существеннее и заметнее (но опять таки только в цифрах, на глаз ее в жизни не заметить, ну если речь об ИйБиЭм совместимых современных машинах идет

[Алексей++]

lapulya,

количество прогонов - 100 (это я о тиках)

какие прогоны были ? Уточни уже об них

вопрос пушистого "почему значения близки к маленькой отметке шкалы " я не понял.

я не совсем правильно выразился - измеренное значение близкО к цене деления (то есть ~10...30 тиков) , и если в случае , скажем, линейки, можно точно сказать что 2 мм - это да, 2 мм , то на пружинных весах с ЦД==1 грамм нельзя точно взвесить 1...5 граммов. Вернее, взвесить то можно, но погрешность растёт сильно (50% - 1 грамм). А вот килограмм взвесится с погрешностью 0,1% .
В общем - пока количество тиков не сделаешь по несколько тысяч в обоих случаях - точности никакой. Ещё к этому присобачиваем кеширование , то есть после парочки прогонов программа вполне может заработать быстрее.
Вот как-то так )

Теперь, нихрена не понятно, при чём тут UpdateData  (я вообще не пользуюсь этим) и вообще - контролы (КОНТРОЛЫ, О БОЖЕ!!! (юмор) ) ? Когда играешь в игру или архивируешь файл - много контролов используешь ?

паотому что объект app создается раньше того момента когда мы в мэйн попадаем

опять не правда, с менй начинается выполнение программы , потом создаётся объект theApp, в котором потом вызывается InitInstance, где создаётся и показывается главное окно с контролами (О БОЖЕ!!! КОНТРОЛЫ!!! (юмор) )

пишите проги больше, соответственно и абсолютная разница будет расти, а вот относительная около 20%,

с какого перепугу то ? Вовсе не правда.

Кстати, проекты - в студию

И ещё кстати - виста не показатель, там даже папка с трудом открывается

[lapulya]

Алексей1153++,

какие прогоны были ? Уточни уже об них

А что уточнять? Я ж говорю 100 запусков под ряд и усреднение кол во тиков, я не знаю чего еще уточнить...

я не совсем правильно выразился - измеренное значение близкО к цене деления (то есть ~10...30 тиков) , и если в случае , скажем, линейки, можно точно сказать что 2 мм - это да, 2 мм , то на пружинных весах с ЦД==1 грамм нельзя точно взвесить 1...5 граммов. Вернее, взвесить то можно, но погрешность растёт сильно (50% - 1 грамм). А вот килограмм взвесится с погрешностью 0,1% .
В общем - пока количество тиков не сделаешь по несколько тысяч в обоих случаях - точности никакой. Ещё к этому присобачиваем кеширование , то есть после парочки прогонов программа вполне может заработать быстрее.
Вот как-то так )

Именно поэтому я 100 раз и запускал, а по поводу кеширования... я вообще не знал что в ОС что-то кешируется (спасибо, почитаю). Но даже с кещированием резельтаты должны быть хорошо взвешены, кеширование же у обох прог должно быть... (запускались они последовательно 100 раз одна потом 100 раз другая)

Теперь, нихрена не понятно, при чём тут UpdateData  (я вообще не пользуюсь этим) и вообще - контролы (КОНТРОЛЫ, О БОЖЕ!!! (юмор) ) ? Когда играешь в игру или архивируешь файл - много контролов используешь ?

Обо всем попорядку:
1. UpdateData ))) ну описался я, конечно UpdateWindow
2. Контролы тут при том, ммм тут мне нужна твоя помощь, разьве при отображении диалога MFC не создает как минимум по одному объекту на каждый контрол (вроде должен) с его инициализацией, регистрацией и т.д. Если НЕ создает, то да, виноват - контролы тут не причем (ну не знаю я MFC), а если коздает, то уж извиняй это все тормоза поотношению к АПИ (там ничего лишнего не создается и не вызывается, даже если писать враппер самому над АПИ, все равно это будет быстрее работать и компактнее в памяти по отношению к врапперам MFC)
3. В игре те же самые диалоги, пинели инструментов и в огромном количестве (одних меток то сколько, везде всего понапимано, тебе скриншот из WoW? У нас стобой пальцев на руках и ногах не хватит, чтобы хотябы половину посчитать)

с какого перепугу то ?  Вовсе не правда.

что именно не правда, то что абсолбтая разница расти будет, дык это ж очевидно? Если у MFC каждый объект в памяти запимает больше место, чем реализация его через АПИ, то два объекта удвоят эту разницу и т.д. отсюда и абсолютное увеличение... или ты имел ввиду что-то другое?

Кстати, проекты - в студию

)))) Ну неееет ну что ж это получается, тебе все покажи, расскажи, докажи и премер еще тебе (сам то ты писать отказался). Не то что мне жалко, вовсе нет, те 20 - 30 минут что я потратил мне не жалко, но хочешь знаний ну хоть чуток напрягись (коль уж ты ни моим словам с теор заключениями, ни тому что я тебе констатирую факт не веришь, точнее подвергаешь сомнению). Это вообще как-то не спортивно...

И ещё кстати - виста не показатель, там даже папка с трудом открывается

)))) Согласен, но мне что теперь застрелиться ))) я ж примеры то для тебя привожу, сам то я и так в результате уверен, хоть в висте, хоть в ХР, хоть в 2000, хоть Вин95, хоть в мобильных версиях Винды (самя подо все кроме висты писал)
 

опять не правда, с менй начинается выполнение программы , потом создаётся объект theApp

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

[Алексей++]

запусков чего ? Программы что ли ? Ну да, тест хороший... Но нужны и другие - на производительность

Контролы тут при том, ммм тут мне нужна твоя помощь, разьве при отображении диалога MFC не создает как минимум по одному объекту на каждый контрол (вроде должен) с его инициализацией, регистрацией и т.д.

ничего я в общем случае не создаю - положил контрол на диалог и забыл про редактор.
Свои производные классы только приходится связывать - но АПИ делает то же самое,  только в АПИ нужно стандартные контролы явно создавать, в в MFC стандартная рутина где то в глубине скрыта - я не вожусь с этим. Но там тот же CreateWindow и всё

В игре те же самые диалоги, пинели инструментов и в огромном количестве (одних меток то сколько, везде всего понапимано, тебе скриншот из WoW? У нас стобой пальцев на руках и ногах не хватит, чтобы хотябы половину посчитать)

в WOW - 3D . Там нет контролов , как в винде, полигон, по которому тыркнули вычисляет видюха. Как тут сравнивать ? Тут интерфейс по иному устроен

Если у MFC каждый объект в памяти запимает больше место, чем реализация его через АПИ,

а зачем ему больше занимать ? Хендл - он и в африке не ананас...
А производные классы - они и в АПИ больше будут занимать

)))) Ну неееет ну что ж это получается, тебе все покажи, расскажи, докажи и премер

мне - ничего доказывать не надо Я вполне доволен жистью, вон в соседнем разделе групповуха начинается )

Код:

но глабальные переменные создаются до входа в майн 

только память под них выделяется и вызывается конструктор.

 А объект то винды создаётся после входа в мейн
Ну тут Джон подскажет, если я ошибся Но вроде это так