Сообщество программистов Autodesk в СНГ
ADN Club => ObjectARX => Тема начата: Baton от 09-03-2020, 01:08:49
-
Доброго времени суток!
Для работы программы желательно увеличить размер стека.
Изменение параметра Stack Reserve Size в Visual Studio ничего не дает.
Увеличение через #pragma comment(linker, "/STACK:4194304") тоже не работает.
Вообще вопрос - для ObjectArx приложения можно увеличить размер стека или нет?
Пояснение: при загрузке программы в Автокад нужно разместить в стеке большие массивы данных как автоматические переменные для загрузки информации в программу. При превышении определенного размера массива Автокад отлетает вместе с моим приложением. Прошу помощи в преодолении проблемы.
-
Пояснение: при загрузке программы в Автокад нужно разместить в стеке большие массивы данных как автоматические переменные для загрузки информации в программу.
Рекомендую просто не размещать в стеке, т.е. не использовать автоматические переменные. arx-приложение - это dll-файл, который использует стек основного exe-файла (acad.exe) (https://docs.microsoft.com/ru-ru/cpp/build/reference/stack-stack-allocations?view=vs-2019)
(https://live.staticflickr.com/65535/49637265342_135425745d_o.png)
Так что сомневаюсь, что получится изменить размер стека только для вашего arx-приложения.
-
Александр Ривилис, Примерно все, приведенное Вами, я читал. Но была надежда. Вы подтвердили мои опасения. Но данные все равно надо загружать. Разобью большие функции, которые надо выполнять при загрузке приложения, на несколько маленьких. Загружать их буду последовательно. Так стек не будет перегружен переменными и вызовами функций. Интересно, сколько стека Автокад отдает ARX приложениям?
-
Так стек не будет перегружен переменными и вызовами функций.
Сомневаюсь очень сильно, что это поможет. Еще раз повторюсь, что в этом случае нужно уходить от автоматических (выделяемых в стеке) переменных. Не хотите использовать динамические - подумайте о статических.
-
Не хотите использовать динамические - подумайте о статических.
Мне нужно сортаменты материалов загнать в динамические списки объектов. Эти списки сортаментов должны быть всегда в памяти, чтобы иметь к ним быстрый доступ. Чтобы создать динамические списки, я и использую массивы данных. Это удобно. Хранить информацию во внешних файлах неудобно. Да и информация с диска считывается медленно.
-
Мне нужно сортаменты материалов загнать в динамические списки объектов.
Глобальные static-переменные переменные должны решить этот вопрос. Хотя мне не нравится весь сценарий запихивания данных в исполняемый файл.
-
Хотя мне не нравится весь сценарий запихивания данных в исполняемый файл.
Это так сложилось исторически, когда данных было мало. Потом пользователи просили расширения данных ну и тихо все это разрасталось. Потом вышли новые ГОСТы и надо поддерживать и старые, и новые ГОСТы для совместимости. При загрузке я все данные запихал в списки моих объектов и потом с ними работаю. Для работы это удобно. Держать данные во внешнем файле - тогда вопрос: в каком формате? Если в текстовом - всем доступно. А это совсем не нужно. В двоичном - я просто не умею это делать. Во внешней DLL - встанет та же проблема с запихиванием всего в DLL. Вообще-то итоговый исполняемый файл ARX со всеми данными и программой небольшой - около 1.5 Mb. Держать массивы в глобальных переменных как-то мне не очень. Может еще есть способы оптимизации?
-
Держать массивы в глобальных переменных как-то мне не очень.
Также как и запихивать их в автоматические переменные. Глобальные переменные хранятся не в стеке.
-
Глобальные переменные хранятся не в стеке.
Я знаю, что они хранятся не в стеке. Но глобальные переменные занимают память все время работы программы.
Спасибо за Ваши ответы. Пока оставлю как есть. Если будет программа вылетать, попробую сделать через глобальные переменные.
-
Но глобальные переменные занимают память все время работы программы.
Ну и что? У вас что там гигабайты данных??? Если у вас там даже данных на десятки и сотни мегабайт, то современный (10-летней выдержки) компьютер этого даже и не заметит. Стек вы собирались сделать на 4 мегабайта. Значит видимо рассчитали, что ваши данные в 4 мегабайта влезут. Так что для статической памяти это не объём...
-
Александр Ривилис,
Переделал программу с данными под глобальные переменные. В принципе работы не много. Просто вынести массивы за пределы функций. Наверное, Вы правы. Так надежнее. Так же прошерстил весь код и убрал рекурсии. Они у меня были при удалении из памяти списков. Все переделал на циклы. Теперь единственное, что осталось, так это поработать над быстродействием, но это уже другая тема. Очень много обращений на создание объектов через new. Ну и потом на delete. Вычитал, что на это тратится много времени. Но для ускорения надо писать свой менеджер памяти. Пока не готов на это.
Спасибо за советы. Вы мне очень помогли.
-
Теперь единственное, что осталось, так это поработать над быстродействием, но это уже другая тема. Очень много обращений на создание объектов через new. Ну и потом на delete. Вычитал, что на это тратится много времени. Но для ускорения надо писать свой менеджер памяти. Пока не готов на это.
Для этой цели нужно сначала убедиться, что проблема именно в выделении памяти, а не в чем-то другом...
-
Для этой цели нужно сначала убедиться, что проблема именно в выделении памяти
Делал тайминги на разные участки кода. Половина времени - сбор информации (это создание объектов для их последующей обработки) и вторая половина - на вычисления и изменение объектов при необходимости. Вычисление и изменение уже отработал все нюансы, а вот сбор информации - это создание моих объектов и их списков через new. Там и тормоза. Пока объектов мало - все быстро, но когда счет идет на тысячи, то начинает немного подтормаживать.
-
Пока объектов мало - все быстро, но когда счет идет на тысячи, то начинает немного подтормаживать.
Обычно помогает выделение памяти непрерывным куском. Например, если знаете, что нужно будет 1000 объектов, то выделяйте память не 1000 раз для каждого из объектов, а один раз на все 1000 объектов.
-
Обычно помогает выделение памяти непрерывным куском
Это я понимаю. Но для этого и надо писать свой менеджер памяти. В инете много примеров. Можно написать менеджер под свои конкретные объекты. Универсальный в принципе не нужен. Но я пока не готов к этому. Нужно время на изучение вопроса, разработку и тестирование, хотя желание такое есть. У меня объекты имеют внутри себя строки, которые тоже требуют динамического выделения памяти, так что объекты не имеют фиксированной длины. Так что не думаю,что легко будет с памятью. Придется повозиться. Все-таки программирование не мое основное занятие. Так что сейчас сделаю перерыв, но следующим шагом будет именно работа с памятью.
-
У меня объекты имеют внутри себя строки, которые тоже требуют динамического выделения памяти, так что объекты не имеют фиксированной длины.
Они не имеют фиксированной длины, но наверняка можно наложить какие-то ограничения (например, 1024 байт на строку) и тогда не выделять под неё память отдельно. Это увеличит объём используемой памяти, но почти наверняка увеличит быстродействие.
-
Александр Ривилис,
Для строк я использую классы CString и AcString. Может в них дело. Сами они занимают мало места и занимают фиксированный объем. Но память под строку выделяют и удаляют, видимо, автоматически. С ними, конечно, удобно работать со строками. Часть членов классов у меня AcString, так как в некоторых случаях удобны для работы с функциями ObjectARX. Далее есть работа с AcDbDictionary, которые привязаны к объектам Автокада. Там надо получать список resbuf, под который тоже требуется динамическое выделение памяти. Так что процесс выделения памяти не такой очевидный, как при простых объектах, фиксированной длины. Будет над чем поломать голову.
-
При замерах времени работы программы есть одна интересная особенность - Автокад 2013 работает стабильно быстрее при всех одинаковых условиях, чем Автокады 2018-2020 примерно процентов на 30-40.