|
|
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
При открытии формы делаю TreeView.Nodes.Add(...) Надо ли при закрытии формы както все это с памяти удалять, а то есть подозрение, что само не удаляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2003, 18:02 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
если логически подойти - то не надо три вью - дочерний контрол для формы ты же не делаешь разрушение для каждого контрола на форме... а практически кто его знает .... а главное как это отследить ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2003, 18:06 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
а главное как это отследить ??? Несколько раз открываю форму - закрываю форму. Access при этом все больше памяти жрет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2003, 18:10 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
делай примерно так Dim N as Mscomctl.Nodes set N=TreeView.Nodes.Add(...) ... set N=Nothing А из памяти удаляется, правда, если посмотреть монитор - всегда остаются пара десятков (сотен) килобайт после закрытия любой формы. Почему -вопрос к разработчиком языка. Я как-то сдела цикл -Открыть -подождать-Закрыть. За пару сотен уиклов памяти сожрало мегабайт 200. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2003, 18:46 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
>Senin Viktor Примерно так и делал, только без set N=Nothing В результате постоянно один узелок частично зависал в памяти. Переделал просто TreeView.Nodes.Add ... (без переменной N). Все освобождается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2003, 21:55 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
>Переделал просто TreeView.Nodes.Add ... (без переменной N). Все освобождается. Все все равно не освобождается. Десяток другой килобайт все равно остануться - независимо от того с форма TreeView или без. Во всяком случае у меня так. А испрользование set N=TreeView.Nodes.Add(...) позволит провести дальнейшие операции над узлам (определить иконку, цвет текста и т.п.) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2003, 09:01 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Виктор, а почему While...Wend? Ведь Do...Loop удобнее хотя бы тем, что есть аварийный Exit Do по дополнительному условию. Tip The Do...Loop statement provides a more structured and flexible way to perform looping. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2003, 10:07 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
2Alexus12 >а почему While...Wend? Ведь Do...Loop удобнее хотя бы тем, что есть аварийный Exit Do "аварийный" выход здесь не нужен. Данное можно решить и через For-Next. И через Do-Loop. Просто так сделано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2003, 12:35 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
А не подскажет ли мне (читать: "себе") многоувожаемый Олл, каким образом можно высвободить отведенную под нечто оперативку в процессе выполнения некой проги? Т.е. предположим, что был создан некий объект (отведена память), затем был создан еще один и еще туева хуча объектов. Затем некий был уничтожен, в результате чего, как бы память должна освободиться, но... каким образом система должна высвободить уже, как бы, не занятый диапазон оперативки? Дефрагментировать рам после каждого терминирования объекта (выхода переменной из области видимости)? При выделении памяти под новый объект/переменную пытаться найти кусочек рама в который можно впердолить создаваемую переменную? Другие варианты? Вот и тает "память" после каждой "формы"... //злой на All... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 00:16 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
> Нуф-нуф Нет, тут кажись не тот случай. Если сделать set N=TreeView.Nodes.Add(...) Затем N добавить в collection, то получается на один объект две ссылки, и практика показывает, что при закрытии формы сначала рушится collection. Но узел на какой ссылается N не удаляется. Тоесть надо добавлять Set N=nothing. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 13:34 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Я не имел в виду конкретно ситуацию с объектами, Access VBA, Приложениями или даже ситуацию с самой ОС. Дело вообще в методах и механизмах управления оперативной памятью. Приведенный ниже текст основывается в 90% случаев на чисто гипотетических предположениях, поэтому буду рад, если кто-нить расскажет как обстаят дела реально. Итак... Есть некий указатель текущей свободной памяти, которую система может выделять под, скажем, хранение объектов и переменных Акссеса. Будем называть этот указатель "ОЗУ-указатель". Смоделируем работу Акссеса (обозначим в начале каждого действия номер шага и образную позицию ОЗУ-указателя: Шаг/Позиция_указателя_после_завершения_действий_шага): 1 / 1 - Запуск Акса; 2 / 2 - Объявление глобальных переменных (резервирование ОЗУ под глобальные переменные); 3 / 3 - Открытие формы (в память грузятся все объекты формы, инициализируются переменные и т.п.); 4 / 4 - Открытие второй формы; 5 / ? - Закрытие первой формы. Здесь давайте поразмышляем... Первая форма закрывается, высвобождая диапазон памяти между 2-й и 3-й позициями ОЗУ-Указателя, но уменьшается ли реальный объем занимаемой приложением памяти? Смещается ли ОЗУ-Указатель свободной памяти на позицию 2? Нет! Нет, потому что у нас все еще активна вторая форма, которая занимает диапазон с 3 по 4 позицию ОЗУ-Указателя. Как должна поступить система? Дефрагментировать ОЗУ? Запомнить его как свободный и при открытии следующих форм пытаться впехнуть что-либо в эти якобы освобожденные кусочки? Если так, то процессор будет занят ТОЛЬКО оптимизацией памяти. Поэтому, определимся, что в шаге 5 указатель так и останется на 4-ой позиции: 5 / 4 - Закрытие первой формы; 6 / ? - Закрытие второй формы; А вот здесь ОЗУ-указатель можно "откатить" до 2-й позиции (реально особождая память), так как и 3 и 4 позиции более не содержат актуальных данных: 6 / 2 - Закрытие второй формы; Усложним задачу введением в шаг 2 глобальной строковой переменной произвольной длинны с присвоением ей значения "Шаг_2" (ключевой момент: 5 символов). На 2-ом шаге для этой переменной выделяется оперативка равная заголовку переменной и непосредственно данным с длинной в 5 символов. В 4-ом шаге (Открытие Второй формы) изменим значение глобальной переменной на "Шаг_5_Будет_ли_откат?" (ключевой момент: 20 символов). Естественно, что в ранее отведенную область ОЗУ новое значение переменной не влезет, поэтому система откажется от "старой" переменной и создаст новую в текущей позиции ОЗУ-указателя, которая у нас на данном шаге равна 4, при этом ОЗУ-указатель будет установлен в 5-ую позицию: ...4 / 4 - Открытие второй формы; ...4а / 5 - Глобальная переменная = "Шаг_5_Будет_ли_откат?" Далее закрываем первую и вторую формы. Будет ли произведен откат? Нет, так как в пятой позиции ОЗУ-указателя хранятся глобальные данные, "живущие" до закрытия проекта, поэтому чтобы использовать "освобожденное" формами ОЗУ необходимо дефрагментировать память и т.п. (см.выше). Если теперь представить, что память занимают формы, переменные, объекты и коллекции, модули, классы, наборы записей и т.п., то лично у меня каких либо особенных притензий к производителям ОС не возникает. Хотя, все это, конечно, имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 19:01 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Я, в принципе, тоже в этом мало понимаю, но представляю себе это дело иначе. Имхо, сам Аксесс использует память без особой оптимизации. При этом постоянно возникают дырки. А оптимизацией занимается ОС, т.е. Windows, как отдельным процессом в свободное время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 19:07 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Возможно и такое, но вот лет так 5 назад я натыкался на утилитку под Вин95, занимающуюся... оптимизацией оперативной памяти на лету! Даже пользовал ее некоторое время (память была тада оч. дорогостоящим удовольствием и приходилось довольствоваться малым), пока в конец не достала увеличившаяся раз в 5 падучесть окон. Именно на этом факте и строятся мои предположения об отсутствии в мелко-мягких механизма оптимизации оперативной памяти. Хотя, с Вин95 много воды утекло, может что и изменилось... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 20:02 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Когда-то Borland в Turbo-Pascal'e описывал подробно механизм выделения памяти. С тех пор думаю многое пошло вперед. Но еще в те времена существовал механизм объединения освободившихся блоков. Таким образом если выделялся блок1, блок2, блок3, после чего освобождался блок1, блок2 в любой последовательности, то пространство блок1+блок2 объединялось в свободный блок и участвовало в следующем выделении памяти. Кроме того было понятия выравнивания на начало сегмента. Тоесть блоки выделялись кратной величины. И лично я считаю, что если в цикле сто раз открыть и закрыть одну и туж форму, и это жрет память, то либо с программой что-то неладно, либо глюки в самом Accesse. ТАК БЫТЬ НЕ ДОЛЖНО! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 23:18 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
это было всего лишь имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:33 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
> что если в цикле сто раз открыть и закрыть одну и туж форму, и это жрет память, то либо с программой что-то неладно, либо глюки в самом Accesse. ТАК БЫТЬ НЕ ДОЛЖНО! Но так есть. Прелагаю всем в этом убедиться на разных операционках и разных версиях Акеса. И это не глюк - это такой VBA. Открываем "Диспетчер задач" и смотрим на память, отводимую под акес Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:48 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Для All: Провел тест по поводу своего гипотетичского предположения (см. пост от 29.05.03 - ). Система: Вин98, Аксесс 2000, оперативка 160 Мб. Индикатор загрузки памяти: стандартный Системный монитор. Анализируемые характеристики памяти: Выделено_памяти / Подкачиваемая_память / Свободная_физическая_память. Количество итераций в тестах: 1000 Перепроверка тестов: дважды Итак... Тест №1: Основан на неусложненной изменением глобальной переменной задаче (см. ). Результат в мегабайтах: 124,1 / 40,4 / 77,6 - на начало теста 124,1 / 40,4 / 77,5 - на конец теста 0 / 0 / 0,1 - разница. Как можно заметить у меня простое открытие и закрытие двух форм не привело к изменению объема занимаемой памяти (кроме уменьшения на 100 Кб объема свободной физической памяти в одном из дублирующих тестов, что можно списать на отсутствие полной чистоты экспериментов, которой добиться в многозадачной среде и при таком бомбовском измерителе памяти оч. сложно). Тест №2: Основан на усложненной задаче, с изменением глобальной переменной после открытия второй формы: 122,0 / 38,6 / 80,4 - на начало теста 123,1 / 39,6 / 79,4 - на конец теста 1,1 / 1,0 / 1,0 - разница. Если присмотреться повнимательнее, то БРОСАЕТСЯ в глаза, что в данном случае объем выделенной памяти увеличился на 1 мег с лишним (основа - первый параметр, со вторыми играет система, поэтому даже не берусь анализировать). Теперь давайте поразмышляем... Если идеи указанные в верны, то память в каждом цикле забивалась описанием двух форм и одной увиличивающейся строковой переменной. Посчитаем... 1,1 Мб = 1100 Кб... 1100 Кб / 1000 циклов = 1,1 Кб памяти на цикл... 1,1 Кб / 2 формы = 0,55 Кб (строковая переменная в расчет не принимается для облегчения задачи рассчетов)... Вопрос: может ли простенькая форма с десятком элементов занимать 0,55 Кб памяти? Если да, то - подтвержена (во всяком случае мной для меня). Если нет, то все-таки некоторая оптимизация памяти присутствует. Поразмышляем дальше... В форме (на вскидку) 50 свойств, в каждом контроле (также на вскидку) еще по 50 свойств, всего 550 свойств... Навряд ли все свойства хранятся в байтовых величинах, поэтому описание одной формы в отведенные 0,55 Кб вроде не влазят... А если подумать? А если подумать, то в форме есть такая фича, как значения свойств контролов по умолчанию (имеется в виду внутрисистемные значения, а не свойство "Дефаулт" контролов). Кажется у Гетца говорится, что если значение свойство контрола совпадает с установленным в форме для него значением по умолчанию, то это значение не хранится, а берется в случае необходимости как раз из этого общего умолчательного значения. Если оно не хранится на диске, то почему бы ему не храниться и в ОЗУ? А коль скоро я, не предусмотрев такой ход, просто понавтыкал эти 10 элементов в форму ничевошеньки в них не изменив, то можно предположить что большая часть данных свойств - умолчательные, т.е. не требующие отдельного хранения... Т.е. в 0,55 Кб вполне может влезть одна форма, что и требовалось доказать... для V. Motchulsky: >...если в цикле сто раз открыть и закрыть одну и туж форму, и это жрет память... Ну не знаю... У меня не жрет. Перед выполнением описанных выше тестов, извращался с одной формой, которую просто открывал и тут же закрывал - никакого ухода памяти... Правда, все же глюк обнаружился... При запуске формы, рекурсивно (на Форм_Лоад) создающую свою копию (Нью_Форм_Я) на 127 рекурсии вылетела табличка с надписью что-то типа "Зарезервированное сообщение", после чего вылетела надпись о нехватке памяти и затем акс аварийно загнулся... Число 127 лично для меня магическое, поэтому далее эксперементировать не взялся :) для Владимир Саныч: После каждого теста я выходил покурить, позвонить, пописать, оставляя компутер на едине с собой без всяких напрягов... Ни-фи-га! Какие были показатели на момент "отхода", такие и остались на момент "возврата"... Никакой оптимизации... даже в свободное время :( для Senin Viktor: к сожалению диспетчера задач я у ся не нашел ( :), поэтому чем богаты... и еще раз для для V. Motchulsky: А можете ли Вы позапускать то, на что "есть подозрение, что само не удаляется" , что бы сообщить нам, удаляется оно все таки или не удаляется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 22:41 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
:((( Клоун, млин... меленький такой шрифтик из-за того, что, блин, оформил ссылку на свой пост от 29.05.03 как "левая квадратная скобка" "1" "правая кв.скобка", что ХТМЛ принял за размер шрифта, поудаляв сами ссылки... Сорри... Если где (3-5 раз употреблял ссылку) просится какое нить слово (несогласованны слова и предложения), то подставляйте то самое, в чем я обманулся... Сорри... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 22:46 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
> После каждого теста я выходил покурить, позвонить, пописать... What can I do... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 23:04 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
>What can I do... I hope nothing... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 23:25 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
> I hope nothing... Оставь надежду, всяк сюда входящий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2003, 00:54 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
Кстати!!! > Никакой оптимизации... даже в свободное время :( По такому эксперименту нельзя судить о том, была ли оптимизация. Можно судить только о том, насколько оптимально или не оптимально сам Аксесс использует память. Под оптимизацией же я имел в виду перемещения занятых/свободных блоков памяти, которыми (по моему предположению) занимается Windows. Увидеть это можно только сделав дамп памяти до и после перекура, а не измерив количество свободной памяти (которое не меняется от перестановки мест слагаемых). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2003, 01:12 |
|
||
|
закрытие treeview
|
|||
|---|---|---|---|
|
#18+
> Оставь надежду, всяк сюда входящий. Угу... После второго (или третьего) моего вопроса к Олл в отдельном топике, надежду положил я... на книжную полочку... > По такому эксперименту нельзя... Вобщем-то, я не особенно уверен в результатах теста, ибо не знаю как работает "Системный монитор", что за что он принимает и как оценивает свободную память... Скорее всего он отслеживает память, занимаемую процессом (приложением), а приложение у нас жрет память, не заботясь об оптимизации ее использования. Как ОС поступает с кусками памяти отведенными под процесс судить не берусь, ибо боюсь быть закиданным шапками из-за вступления в открытый спор с профи. На счет дампа памяти, то :) хотел бы я посмореть на смельчака, который отважится на эдакий подвиг! Я лично нет... В целом делаю вывод, что забивать себе голову (особенно) на счет памяти пожираемой ВБА не стоит, ибо не так уж он и прожорлив. ИМХО сейчас легче купить дополнительную сотню мегов оперативки (дабы компенсировать дыры, возникающие во время сеанса работы), нежели потратить кучу времени на оптимизацию кода, с целью повышения эффективности использования памяти (имеется в виду кода, как составляющей ВБА, а не кода, как составляющей алгоритма). На счет покупки памяти - что-то типа шутки... ИМХО неправильный алгоритм или вообще комплексное решение задачи (не теми средствами) - самый первый враг памяти, а не "забытые" в ФОРМАХ ссылки на объекты, ибо при разрушении формы все переменные выходят из области видимости, с соответствующими последствиями... Из опыта: хде-то в соседнем топике я рассказывал, что переделывал интерфейс в жутчайше спроектированной и реализованной БД ("жутчайше" - здесь "ужасно плохо"). До переделки система через раз обязательно ругалась на нехватку памяти. После переделки по большей части, только интерфейсной стороны проекта, сообщения исчезли... У осталась копия первоначальной БД и можно попытаться отловить в ней место утечки памяти, но... но, как я уже и сказал, для меня эта проблема актуально не стоит - память как-то самам собой, лично у меня, не "утекает"... Но все это, конечно, имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2003, 08:55 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32172370&tid=1681302]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 343ms |

| 0 / 0 |
