Здравствуйте, FR, Вы писали:
КД>>Ладно фиг с ним. Но я вот что думаю. BCB5 компилирует раза в три быстрее VC8 (в два — точно). Родной RW-STL, получается, тоже достаточно эффективен. И все это дело датируется 2000 годом. Но народ упорно, с пеной у рта доказывал, что BCB — тормоз
FR>А ты BDS какой ни будь попробуй запустить по сравнению с ними VC8 летает
Давайте не будем путать компилятор и IDE. BDS (2006) я ... мучал год назад
Здравствуйте, Коваленко Дмитрий, Вы писали:
FR>>А ты BDS какой ни будь попробуй запустить по сравнению с ними VC8 летает
КД>Давайте не будем путать компилятор и IDE. BDS (2006) я ... мучал год назад
Здравствуйте, ArtDenis, Вы писали:
КД>>С удовольствием выслушаю другие гипотезы о причинах такого резкого снижения производительности.
AD>Могу предположить, что дело в какой-то глупой ошибке, которая не проявляет себя при компиляции в BCB
Смешно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, ArtDenis, Вы писали:
AD>>Могу предположить, что дело в какой-то глупой ошибке, которая не прояляет себя при компиляции в BCB
AD>Кстати, надеюсь запускается именно релиз и не из под IDE?
Ржунемогу
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[4]: Производительность и смешивание компиляторов
Всё-таки похоже на память и сторки...
У меня был наобототный случай, когда я в большой проект на дельфи вставил FastMM — всё залетало.
У Borland-а вроде как куча всё равно единая могла быть — borlandMM.
Тогда просадка вполне обоснованная.
Я бы посоветывал таки пройтись профилятором VTune или AQTime.
Оба понимают отладочную инфу и от MS, и от Borland-а.
Тока для Borland-а надо указать чтобы файлом сгенерил.
Ну и всякие мелочи посмотреть, типа строковые параметры/возвраты как передаються/передавались сравнить...
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Привет всем.
КД>Тема сообщения, конечно, немного сумбурная, но лучше сформулировать не смог
КД>Ситуация такая.
КД>Есть большой программный комплекс, состоящий из множества COM-модулей. Изначально все компилировалось на BCB5 (практически без оптимизации). В течении многих лет комплекс шлифовался во всех направлениях. Производительность была более менее приемлемая. Тут, в свете увядания любви к BCB, пересобрали модуль с сервисными COM-объектами на VC8 (speed-оптимизация по максимуму). Объекты из этого модуля юзаются практически повсеместно.
КД>Ну дык вот. Производительность упала на глазах — раз в пять. Видно прямо при перерисовке окон (сделаны на BCB5) — отображаемые данные тащатся из объектов, обcлуживаются именно этим сервисным модулем, откомпилированным на VC8. Если этот модуль заново пересобрать на BCB5 — все нормально.
КД>Модуль c GUI (собран на BCB5) компилируется со статической библиотекой. КД>Сервисный модуль всегда компилировался с использованием динамической библиотекой — сс3250mt.dll (BCB5) и MSVCP80.dll,MSVCR80.dll (VC8).
КД>То есть, каждый модуль всегда жил со своей собственной кучей.
КД>Я вот чего думаю. BCB5 юзает RW-STL, а VC8 — другую STL. Сдается мне главное различие в том, что в RW-STL basic_string юзает счетчики ссылок, а VC8-STL всегда копирует строки. В результате получается ахтунг.
КД>С удовольствием выслушаю другие гипотезы о причинах такого резкого снижения производительности.
КД>PS. Профайлера у меня нет, так что даже и не предлагайте
Я может чего и невкурил, но здается мне что проблема не в опциях копилятора, а в апартаментах. Если COM-объект собран
как... блин забыл как называется, уже два года не занимался этим, типа как однопоточный. Короче точно проблема была
когда один Borland-ский компонент вызывал visual-ский то вызов шел через proxy-stub, со всеми от сюда вытекающими последствиями
(несмотря на то, что они находились в одном апартаменты). При связки visual-visual или borland-borland таких проблем
не возникает, т.к. вызовы идут напрямую. Соответственно программа ниписанная на bc юзающая vc-компоненты работает через
прокси — отсюда и падение производительности
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, s_viy, Вы писали:
КЛ>[]
КЛ>Апартмент все-лишь определяется ключиком ThreadingModel у соответствующего CLSID. Как это может зависеть от сборки — не знаю.
Единственное, что bcc может для STA объектов считать ссылки через InterlockedXXX. Но это может быть сильно заметно только на мультипроцессорных системах.
Re[4]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КЛ>>Апартмент все-лишь определяется ключиком ThreadingModel у соответствующего CLSID. Как это может зависеть от сборки — не знаю.
КЛ>Единственное, что bcc может для STA объектов считать ссылки через InterlockedXXX. Но это может быть сильно заметно только на мультипроцессорных системах.
BCC вообще ничего не считает. Для работы со счетчиками ссылок я дейстивительно использую InterlockedXXX. Всегда.
Не замечал, чтобы это как-то влияло на производительность многопроцессорной машины Зато сплю спокойно.
Вот когда используются мьютексы вместо CS — это да. Оно и на однопроцессорной машине с однопоточной программой заметно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[5]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КД>>Не замечал, чтобы это как-то влияло на производительность многопроцессорной машины Зато сплю спокойно.
КЛ>дык, синхронизация кешей каждого из ядер
Спасибо. Будем думать
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, s_viy, Вы писали:
_>>Я может чего и невкурил, но здается мне что проблема не в опциях копилятора, а в апартаментах....
КД>Умоляю. У меня такой "страсти-ужасти" точно нет
КД>Компоненты (и интерфейсы) все мои, все в одном процессе, проксей нет, вызовы идут не через IDispatch, а напрямую.
А ты как в bc импортируешь? В bcb обычно их импортируют через среду, а не создают вручную — среда сама генерит прокси
и вызовы идут через нее. ты в дебаге смотрел пошагово как вызовов идет?
Re[4]: Производительность и смешивание компиляторов
Здравствуйте, s_viy, Вы писали:
КД>>Компоненты (и интерфейсы) все мои, все в одном процессе, проксей нет, вызовы идут не через IDispatch, а напрямую.
_>А ты как в bc импортируешь? В bcb обычно их импортируют через среду, а не создают вручную — среда сама генерит прокси _>и вызовы идут через нее.
Под проксей я понимал натуральные комовские proxy (компилируемый из файлов генерируемых midl.exe)
Работа с компонентами (точнее с их интерфейсами) ясный пень идет через обертки. Обертки всегда писал сам. Так сложилось. Если интересно, как это выглядит, то скачивай дистрибутив провайдера и посмотри файлы в каталоге lib/Components/ScriptControl.
Кстати, COM-объекты я пишу также на базе своей библиотеки. Без использования ATL. Опять же исторические причины.
Интерфейсы, аналогично, описываются руками и явно компилируются midl-ом.
Короче — "все сам, все сам, своими руками"
> ты в дебаге смотрел пошагово как вызовов идет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[6]: Производительность и смешивание компиляторов
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, OdesitVadim, Вы писали: R>>MSVC 6 SP4 немного отличается от MSVC 8 SP1
FR>Угу только тромозить на выделении мелких объектов не перстал
Давайте разберемся. Принцип работы борландовского менеджера памяти — сразу стребовать от системы здоровенный кусок памяти, а потом уже по запросам из кода отрезать каждому инстансу по чутка. Когда этот лапоть заканчивается, будет стребован еще один здоровый кусок. Минус — излишние пожирания памати процессом (на что всегда тыкают апологеты MS VS), но плюс — это высокая скорость инстанциирования объектов на куче. MS VS идет другим путем, и в этом тоже есть здравое зерно. Просто забота о выборе подходящего аллокатора переходит на программиста. Да, типовой аллокатор MS VS будет тормозить на выделении памяти под мелкие объекты, особенно на многопоточных проектах. Но с другой стороны, не нравится — пользуйте кастомный аллокатор. Ибо нарисовать системный сервис а-ля hello world, который по дефолту сожрет под себя мегабайт эдак десять-двадцать рабочей памяти "так просто, на будущее" — приятного мало.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>PS. Профайлера у меня нет, так что даже и не предлагайте
Прекратить гадать на кофейной гуще, а взять профайлер. Я конечно понимаю, что тот, кто без доп инструментов силой мысли найдет причину, достоин не то что уважения, а памятника, но... возьмите ж вы профайлер.
Зато сплю спокойно.
