Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Вниз

Правильное использование 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]

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


 
Dennis I. Komarov ©   (2012-05-23 21:06) [29]

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


 
Pcrepair ©   (2012-05-23 21:25) [30]

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


 
Dennis I. Komarov ©   (2012-05-23 21:47) [31]

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


 
Ega23 ©   (2012-05-23 22:15) [32]


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


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


 
Ega23 ©   (2012-05-23 22:16) [33]


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


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


 
KSergey ©   (2012-05-24 05:50) [34]

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

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


 
KSergey ©   (2012-05-24 05:54) [35]

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

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

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


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

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


 
Pcrepair ©   (2012-05-24 09:36) [37]

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

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


 
Jeer ©   (2012-05-24 10:29) [38]


> 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 лет, однако мне сдается, что ситуация вряд ли сильно изменилась.


 
Ega23 ©   (2012-05-24 11:01) [39]


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


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


 
Pcrepair ©   (2012-05-24 11:42) [40]

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



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.56 MB
Время: 0.056 c
2-1339967231
ankazh
2012-06-18 01:07
2013.03.22
DBLookupComboBox


8-1227079093
Andrey_ka
2008-11-19 10:18
2013.03.22
как заставить окно перерисовываться?


2-1334809726
leklerk
2012-04-19 08:28
2013.03.22
Компоненты формы не доступны в другой форме


15-1346224640
Grimm
2012-08-29 11:17
2013.03.22
git-клиент


15-1332230683
Ega23
2012-03-20 12:04
2013.03.22
Ну и что, что пост? Когда нам это мешало?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский