Правильное использование DLL

← →
Pcrepair © (2012-05-22 11:00) [0]

Добрый день
Есть программа, обрабатывающая строковую информацию и программа работает.
Структурно программа состит из основного модуля и дополнительных модулей в которых размещены все функции и процедуры, обрабатывающие строковую информацию. В основном модуле только форма и обработчики событий, вызывающие функции.
Есть идея вынести все процедуры и функции из дополнительных модулей в несколько DLL, чтобы уменьшить потребление памяти, как об этом рассказывается в теории.

Вопрос для тех кто имел дело с подобной структурой программы: какие реально будут плюсы и проблемы

← →
Ega23 © (2012-05-22 11:13) [1]

Выносить в dll имеет смысл в случае:
1. Данная dll используется более чем одной программой.
2. Данная dll может часто заменяться и нужно это делать без перекомпилляции всего exe.
3. Данную dll пишет негр на аутсорсе, ты вообще без понятия, что это такое, чёрный ящик, для тебя есть только вход и выход.

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

← →
Anatoly Podgoretsky © (2012-05-22 11:30) [2]

А читай не читай разницы нет.

← →
Медвежонок Пятачок © (2012-05-22 12:07) [3]

создать свой маленький локальный dll hell с сапером и тестировщицами может каждый.

← →
Давайте будем жрать! (2012-05-22 12:17) [4]

YES WE CAN! %-)

← →
AV © (2012-05-22 12:46) [5]

имхо, вообще, так

> Выносить в dll имеет смысл в случае:
> 1. Данная dll используется более чем одной программой.
даже более чем 2(3). Для двух можно дублировать, ибо проблем может быть больше, чем выгоды

> 2. Данная dll может часто заменяться и нужно это делать
> без перекомпилляции всего exe.
Если перекомпиляция занимает более часа времени
или у клиентов диал ап :)
ибо проблем может быть больше, чем выгоды

← →
SergeyIT © (2012-05-22 18:32) [6]

4. (забыли). Если длл и основная программа написаны на разных языках (здесь тоже можно много огрести)

← →
Pcrepair © (2012-05-22 19:23) [7]

использовать ДЛЛ думается по следующим причинам:
1. в текущем варианте программа отъедает до 100 мб памяти(в процессе обработки данных), но это однопользовательский режим. в многопользовательском режиме когда одновременно ресурсы идут на десятки, возможно сотни пользователей, по теории, динамическое подключение ДЛЛ должно снизить затраты памяти
2. в настоящий момент алгоритм обработки данных очень несовершенен. в перспективе необходимо будет алгоритмы радикально усложнять, притом что сама структура обработки меняться не будет. по теории тут как раз хорошо использовать ДЛЛ: входные-выходные параметры теже самые, заменил одну ДЛЛ на другую и вроде проблем нет
Что касается:
- Если длл и основная программа написаны на разных языках
- Если перекомпиляция занимает более часа времени
- Данная dll используется более чем одной программой.
- Данную dll пишет негр на аутсорсе
и прочие доводы такого рода - все это полная чепуха
меня интересует квалифицированный ответ на 1 и 2 пункты

← →
Давайте будем жрать! (2012-05-22 19:57) [8]

> по теории, динамическое подключение ДЛЛ должно снизить затраты
> памяти
Что за странная теория?

> заменил одну ДЛЛ на другую и вроде проблем нет
Так и экзешник заменил один на другой и проблем нет.

← →
Медвежонок Пятачок © (2012-05-22 20:16) [9]

ну он видимо как бы думает, что длл съедает столько памяти, сколько весит сама.
и если сто процессов ее загрузят, то будет стократная экономия.

← →
Медвежонок Пятачок © (2012-05-22 20:28) [10]

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

Если код обработки вынести в длл, запустить два процесса или потока, которые начнут юзать эту длл, то сожрется 100 мб памяти умножить на количество потоков юзающих обработку.

← →
Pcrepair © (2012-05-22 21:31) [11]

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

← →
Ega23 © (2012-05-22 21:36) [12]

> возможно динамическое подключение функций из ДЛЛ автоматом
> решит проблему утечки памяти?

Голосую за орех

← →
Медвежонок Пятачок © (2012-05-22 22:11) [13]

епта. конечно решит. причем "автоматом".
а уж если функции динамически грузить, а не статически, то оно еще и генерировать память будет, а не потреблять.

← →
Cobalt © (2012-05-22 22:28) [14]

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

← →
Cobalt © (2012-05-22 22:36) [15]

Аааа, веб-сервер )))

ReportMemoryLeaksOnShutdown работает как минимум с 2007-ой студии

или в FastMM http://www.gunsmoker.ru/2009/05/blog-post_24.html

← →
Сергей М. © (2012-05-22 23:30) [16]

> вынести все процедуры и функции из дополнительных модулей
> в несколько DLL, чтобы уменьшить потребление памяти, как
> об этом рассказывается в теории

Ты эту траву больше не кури - это неправильная трава)

← →
Сергей М. © (2012-05-22 23:33) [17]

> как об этом рассказывается в теории

Похоже г-н Архангельский опять виртуальных тумаков очередную охапку схлопочет - оттуда "теорией" попахивает)

← →
Ega23 © (2012-05-23 00:24) [18]

> Похоже г-н Архангельский опять виртуальных тумаков очередную
> охапку схлопочет

Дедушка помер, ему всё равно

← →
Германн © (2012-05-23 00:38) [19]

> Ты эту траву больше не кури - это неправильная трава

Автор её обожает. Достаточно посмотреть все его топики на 9 (если не ошибаюсь) форумах за последнее время :)

← →
Anatoly Podgoretsky © (2012-05-23 05:51) [20]

> Pcrepair (22.05.2012 19:23:07) [7]

1. Отвечали, будет увеличение объема памяти, особенно если используется RTTI

2. заменил и получил DLL hell, то есть проблем станет больше и они станут
более сложными.

← →
Anatoly Podgoretsky © (2012-05-23 05:53) [21]

> Медвежонок Пятачок (22.05.2012 20:28:10) [10]

У него одна программа с одним потоком, а несколько программ по его мнению
это ерунда.

← →
Anatoly Podgoretsky © (2012-05-23 05:55) [22]

> Ega23 (23.05.2012 00:24:18) [18]

Но нам то приходится за ним подметать. Так что не все равно.

← →
Давайте будем жрать! (2012-05-23 07:52) [23]

> 2. заменил и получил DLL hell, то есть проблем станет больше
> и они станут более сложными.
"Однажды для решения проблемы вы решаете воспользоваться регулярными выражениями. Поздравляем! Теперь у вас две проблемы."

← →
Dimka Maslov © (2012-05-23 09:55) [24]

> Cobalt © (22.05.12 22:28) [14]
>
> Что за программа, остается только гадать

Гадать не надо. Программа - супер-пупер поисковая система, убийца Гугла. Автор уже давно её пишет.

← →
KSergey © (2012-05-23 18:02) [25]

> SergeyIT © (22.05.12 18:32) [6]
> 4. (забыли). Если длл и основная программа написаны на разных
> языках (здесь тоже можно много огрести)

Это огребание не имеет отношения к делу. Ровно тоже самое легко огрести и при написании на одном языке, если не понимать как оно устроено.

А вот как вполне неплохой способ объединить куски программы, написанные на разных языках - то dll тут как раз очень подходит.

← →
Dennis I. Komarov © (2012-05-23 19:31) [26]

> Есть идея вынести все процедуры и функции из дополнительных
> модулей в несколько DLL, чтобы уменьшить потребление памяти,
> как об этом рассказывается в теории.

Есть идея лучше: посмотреть на код и оптимизировать его, чтоб не жрал столько памяти...

← →
Jeer © (2012-05-23 19:56) [27]

> А вот как вполне неплохой способ объединить куски программы,
> написанные на разных языках - то dll тут как раз очень
> подходит.

+1

Стандартно пользуюсь такой связкой: D7 - интерфейсно-управляющая часть + C ( Intel C comp ) - DLL расчетная.

← →
Pcrepair © (2012-05-23 20:29) [28]

Какие есть еще способы не усложнять ЕХЕ файл, оставить в нем только "алгоритмический каркас" программы, а обработку данных вынести куда еще, так чтоб модифицировать алгоритм обработки данных можно было отдельно, не трогая основную программу и остальные "обработчики данных"(их может быть много - десятки и даже сотни)?
может сделать много ЕХЕ файлов, диспетчер, который будет их включать-выключать и использовать СОМ для передачи данных между ЕХЕ?

Упс, бредогенератор хороший :)
Сперва хотим юзать dll дабы на памяти экономить, теперь ищем способы, чтобы вынести из программы часть кода - много эхешников...

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

Разрабатываешь стандарт ввода\вывода данных, пишешь библиотеки согласно стандарту, потом можешь подсовывать что надо, можешь выбирать метод обработки исходя из присутствующих библиотек и т.п.
тип библиотек выбрать в зависимости от потребностей, bpl тоже библиотека

> их может быть много - десятки и даже сотни

Разве это много?
И какой смысл их выносить? Не, если кто-то другой будет свои писать, a-la Plugin, тогда да, имеет смысл. А просто так, ради выноса - увеличение вселенской энтропии.
Ну будет у тебя 500 юнитов в проекте, и чо?

> , так чтобы основную форму и другие модули с функциями не
> трогать - не компилировать все вместе

Объясни, в чём прикол? У тебя проект собирается 2.5 часа?

> Jeer © (23.05.12 19:56) [27]
> C ( Intel C comp ) - DLL расчетная.

Почему не MS? реально лучше показатели? какие?
Или используются какие-то спецовые библиотеки интеловские?

> Pcrepair © (23.05.12 21:25) [30]
> обработки в функциях, но по отдельности, так чтобы основную
> форму и другие модули с функциями не трогать - не компилировать все вместе

Уточните, пожалуйста, что именно хочется добиться: не трогать или не компилиорвать вместе?
Ну это же разное совершенно. Не понятна просто цель деания. Есть подо-зрение, что вы для достижения своих полезных целей выбираете какие-то бредовые средства, лишь усложняющие без толку жизнь.

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

← →
Давайте будем жрать! (2012-05-24 07:50) [36]

Автор, это вообще коммерческая разработка или студенческое самообразование?

ни то и не другое
просто выясняю, какие есть варианты, как говорят англичане: "одну и ту же кошку можно ободрать разными способами"

доп.вопрос: хочу ввести ЛОГ обработки исключений(ну там свой класс написать и его обрабатывать), если переведу модули на ДЛЛ это усложнит возможность получения точного адреса ошибки?

> KSergey © (24.05.12 05:50) [34]
>
> > Jeer © (23.05.12 19:56) [27]
> > C ( Intel C comp ) - DLL расчетная.
>
> Почему не MS? реально лучше показатели? какие?
> Или используются какие-то спецовые библиотеки интеловские?
>

Эффективность кодогенерации выше, я даже как-то затеял сравнение компиляторов разных ( pas и c ). Старожилы должны помнить тут этот проект.

Ага, даже нашел - было это ровно 10 лет назад :)

http://s019.radikal.ru/i603/1205/b5/36b31dbf858c.jpg

http://i021.radikal.ru/1205/6e/d270384962bd.jpg

Понятно, что прошло уже 10 лет, однако мне сдается, что ситуация вряд ли сильно изменилась.

> если переведу модули на ДЛЛ это усложнит возможность получения
> точного адреса ошибки?

Давай ты сначала ответишь на вопрос: "Что такое dll?"
Вот прямо вот здесь.
И пока ты не ответишь, лично я тебе ни капельки не помогу, ибо скорее всего это будет помощь во вред.

бабушка ЕГА, вот прям с хугля, специально для тебя:
http://www.corem.ru/article/article01/art00213.html

Правильное использование DLL Найти похожие ветки