dwg.ru forum rss xml
| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму |

Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Оптимизация обработки большого числа элементов

Оптимизация обработки большого числа элементов

Версия для печати
 
Ответ
Опции темы Поиск в этой теме
Непрочитано 15.09.2013, 04:25
Оптимизация обработки большого числа элементов
АлексЮстасу
 
топограф, технолог
 
Москва
Регистрация: 24.05.2009
Сообщений: 2,551

АлексЮстасу вне форума Вставить имя

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

Как непосвещенный, я предполагаю, что в dwg-файле элементы хранятся в целом просто в порядке их поступления, т.е. их взаимные связи (соединение, наложение, пересечение и т.п.) никак не описаны, и их взаимное положение никак не структурировано, не описано. Это правильно? И поэтому, если действовать в лоб, в подобных программах приходится определять отношение всего со всем, и, возможно, не один раз?
Если же как-то ловко описать взаимное положение и/или взаимные связи элементов, то можно будет анализировать не все элементы, а только взаимно связанные или указанным образом расположенные. Что в теории скажется на скорости работы.

И подвопрос: для файлов примерно какого размера (+-полмегабайта) или какого числа элементов (+-1000), или числа вершин элементов (+-1000) подобные ухищрения имеют смысл на не очень мощных и на хороших компьютерах? Эмпирически-экспертно, конечно.
Просмотров: 23908
 
Непрочитано 19.09.2013, 10:37
#81
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


Понятно, а какие нибудь подробности о типе индекса известны или "черный ящик"? Если распологаешь свободным временем, сделай пожалуйста тоже для nonregular и nonregular2 - очень интересует сравнение результатов для легко и трудноиндексируемых данных
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 19.09.2013, 10:41
#82
trir


 
Регистрация: 18.12.2010
Сообщений: 2,431


в документации написано, что это R-дерево
Времени сейчас нет, к сожалению...
trir вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 19.09.2013, 16:03
#83
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


Цитата:
Сообщение от hwd Посмотреть сообщение
Как видим в файле, объёмом 51Мб на то, чтобы в итерации перебрать 736 323 примитива, уходит 0,278 сек. А теперь разделите 0,278 на 736,323 и узнаете, за какое время просмотрено 1000 элементов: 0,000378 сек.
Есть ли у нас шанс увидеть цифры для создания пересечений с использованием этого способа?
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 20.09.2013, 14:36
#84
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


trir
Переодически подумываю переделать бинарное дерево в R, но чето напрягает то что объемы могут пересекаться - неоднозначно както - будут трудности с быстрой перестройкой при изменении части чертежа. В бинарном все просто - примитив сдвинули, вышел за пределы объема - переношу его на уровень выше и так пока не окажется в объеме. Если какаято нода оказывается переполненной, то перестройка касается только ее и дочерние ноды. В R всё сложнее - всё перестраивать придется чаще чем бинарное.

АлексЮстасу
В продолжение темы. Я для наглядности чуток переделал процедуру постройки дерева, чтоб выудить побольше информации о структуре
Резльтаты для regular.dxf с пояснениями:
Код:
[Выделить все]
Running command:RebuildTree
Total entities: 20000
Max tree depth: 16
Max in node entities: 10
Create tree...
Rebuild drawing spatial:  0.07 second
Done
as a result: //по факту получилось:
Total entities: 20000 //всего примитивов
Total nodes: 3105 //всего нод
Total overflow nodes: 264 //всего "переполненных" нод, т.е. в которых больше 10 примитивов
Fact tree depth: 11 //глубина дерева по факту
by levels: //далее детализация по уровням вложенности
level 0 //уровень 0 - корневая нода
  Entities: 0//примитивов на уровне
  Entities(%): 0.00//тоже в процентах
  Nodes: 1//нод на уровне
  Overflow nodes: 0 //переполненных нод на уровне
level 1 //следующий уровень вложенности и т.д.
  Entities: 80
  Entities(%): 0.40
  Nodes: 2
  Overflow nodes: 2
level 2
  Entities: 199
  Entities(%): 1.00
  Nodes: 4
  Overflow nodes: 4
level 3
  Entities: 239
  Entities(%): 1.20
  Nodes: 8
  Overflow nodes: 8
level 4
  Entities: 496
  Entities(%): 2.48
  Nodes: 16
  Overflow nodes: 16
level 5
  Entities: 843
  Entities(%): 4.22
  Nodes: 32
  Overflow nodes: 32
level 6
  Entities: 917
  Entities(%): 4.59
  Nodes: 64
  Overflow nodes: 63
level 7
  Entities: 1570
  Entities(%): 7.85
  Nodes: 128
  Overflow nodes: 98
level 8
  Entities: 1866
  Entities(%): 9.33
  Nodes: 256
  Overflow nodes: 38
level 9
  Entities: 2612
  Entities(%): 13.06
  Nodes: 512
  Overflow nodes: 3
level 10
  Entities: 6310
  Entities(%): 31.55
  Nodes: 1024
  Overflow nodes: 0
level 11
  Entities: 4868
  Entities(%): 24.34
  Nodes: 1058
  Overflow nodes: 0
Резльтаты для nonregular.dxf:
Код:
[Выделить все]
Running command:RebuildTree
Total entities: 20000
Max tree depth: 16
Max in node entities: 500
Create tree...
Rebuild drawing spatial:  0.03 second
Done
as a result:
Total entities: 20000
Total nodes: 31
Total overflow nodes: 7
Fact tree depth: 4
by levels:
level 0
  Entities: 5134
  Entities(%): 25.67
  Nodes: 1
  Overflow nodes: 1
level 1
  Entities: 3675
  Entities(%): 18.38
  Nodes: 2
  Overflow nodes: 2
level 2
  Entities: 5105
  Entities(%): 25.52
  Nodes: 4
  Overflow nodes: 4
level 3
  Entities: 2689
  Entities(%): 13.44
  Nodes: 8
  Overflow nodes: 0
level 4
  Entities: 3397
  Entities(%): 16.99
  Nodes: 16
  Overflow nodes: 0
Собственно как оно и предпологалось в первом случае основная масса примитивов находится ближе к концу дерева, во втором почти всё в начале и все ноды переполнены.
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 22.09.2013, 04:18
#85
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Нода в моей реализации - ограничивающий объем+плоскость делящая ноду+ссылка на ноду "левее" плоскости+ссылка на ноду "правее" плоскости+список примитивов которые пересекаются плоскостью

1.На вход приходит срисок примитивов+уже посчитаный ограничивающий объем всех примитивов
2.создаем ноду
3.если (примитивов<примитивов в ноде)или(глубина дерева>максимальная глубина берева) то пишем все примитивы в список пересекающихся плоскостью, выходим возвращая созданную ноду
3.выбираем плоскость разбиения (тут я прибумывал всякие хитрые способы, но просто разбивать пополам перпендикулярно самой длинной оси ничють не хуже всяких хитростей)
4.список примитивов делим на 3 списка 1-левее плоскости, 2-правее плоскости, 3-пересекаются плоскостью
5. пишем список 3 в список пересекающихся плоскостью
6. ссылка на ноду "левее" плоскости=рекурсивный вызов п.1 со списком 1 и его ограничивающим объемом
7. ссылка на ноду "правее" плоскости=рекурсивный вызов п.1 со списком 2 и его ограничивающим объемом

на выходе получается рекурсивное дерево ограничивающих объемов с перечнем примитивов в него попавших. разбиение продолжается пока не будет достигнута максимальная глубина или количество примитивов в ноде не будет меньше заданного
Интересно, сколько времени занимает получение списка примитивов?
И еще немного все-таки вопросов от малопосвещенного и неопытного:
1. Вхождение примитивов в объем или пересечение с режущими плоскостями рассматривается по всем вершинам примитивов или по их габаритам?
2. Как хранятся описания самих узлов (объемов)?
3. Один и тот же примитив может входить во множество объемов разного уровня?
4. В первом, верхнем узле хранятся все элементы?
5. На нижнем уровне каждый примитив входит только в один узел? (Пересекаемые плоскостями не в счет).
6. Пересекаемые плоскостями примитивы описываются только один раз - в том узле, в котором они первый раз были пересечены?
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 22.09.2013, 12:16
#86
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


>>Интересно, сколько времени занимает получение списка примитивов?
Максимально быстрое, т.к. внутри программы имеется прямой доступ ко всем структурам данных по указателям (а не по идентификаторам как в примере hwd). в том числе к спискам примитивов и самим примитивам - это положительно сказывается на скорости, но требует аккуратности - чуть что не так - вылет
1. На этапе аостройки "дерева" работа осуществляется только с габаритами примитивов, что из себя представляет примитив - безразницы
2. AABB описаны в виде 2х точек - левая-нижняя-ближняя и правая-верхняя-дальняя - диагональные точки ограничивающего объема
3. Примитив может находится только в одной "ноде"
4. Нет только те объем которых пересекся плоскостью и соответсвенно их невышло "разбить двльше"
5. "Пересекаемые плоскостями не в счет" я неверно сразу выразился - пересекаемый - значит он остается в этой нооде. и соответственно "список пересекаемых" это и есть примитивы лежащие в этой ноде
6. да. см п.3 и п.5

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

Последний раз редактировалось zamtmn, 22.09.2013 в 21:04.
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 23.09.2013, 04:43
#87
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


Т.е., чтобы найти все ближайшие примитивы рядом с какой-нибудь точкой, нужно найти соответствующий узел (или узлы) нижнего уровня, примитивы в нем, а потом все примитивы, пересеченные плоскостями всех соответствующих старших узлов?
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 23.09.2013, 06:52
#88
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


Можно сразу пробежать всё с корня отбраковывая ноды которые не попадают в объем (p-l,p+l), в остальных перебирая примитивы
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 23.09.2013, 21:30
#89
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


В теме написано аж на пять страниц, а сухой остаток что-то жидковат
1. Узнали, что пространственные базы данных (не Автокад) используют оптимизацию. Даже узнали, что в каком-то случае это R-дерево. И получили рекомендацию использовать k-d tree.
2. Узнали, что можно очень эффективно оптимизировать считывание, просмотр огромного числа примитивов. С помощью .NET (реализовано), и, возможно, ARX (не испробовано).
3. Узнали, что в самодельном CAD, работающем с dxf-файлами, можно писать на Паскале чрезвычайно эффективные программы обработки данных. В том числе мы узнали подробности реализованного для этого CAD оригинального алгоритма оптимизации деревом собственной конструкции.
4. Узнали, что имеющиеся программы (создания пересечений) под Автокад могут вообще не обрабатывать тяжелые файлы.
Не узнали ни об одной реализации под Автокад оптимизации обработки геометрических отношений данных.
Не произошло обсуждения предложенных алгоритмов обработки геометрических отношений данных. Если не считать моих глупых вопросов и законного ответа zamtmn, что древовидные структуры - признанный метод оптимизации.
Итого: исходный вопрос об оптимизации обработки геометрических отношений элементов файлов в Автокаде фактически не обсуждался.

Все-таки что-нибудь скажете про мой алгоритм оптимизации регулярным разделением файла?
Цитата:
Сообщение от trir Посмотреть сообщение
Книжки читать видимо не модно, то что вы изобретаете - называется k-d дерево
Мне кажется, что регулярное разбиение файла на ячейки - не дерево. Но включает и преимущества деревьев.
Цитата:
Сообщение от zamtmn Посмотреть сообщение
Добавте в алгоритм пару пунктов:
-Лучше ввести древовидную структуру данных, т.к. 1)еще больший профит за счет отбраковки всех дочерних "подпространств" путем отбраковки вышестоящего, 2) реальные а не подготовленные данные наврятли можно вписать в какую либо "сетку" - всегда будут примитивы которые будут всё портить - пересекать границы в которые хорошо вписываются другие примитивы, 3) удобно "ограничить" процесс построения такого дерева количеством примитивов в "листах" и глубиной вложенности
-В случае наличия в данных "длинных" примитивов - например полилиний с большим кол-вом сегментов ваш алгоритм стоит применять и внутри примитивов (т.е. грубо говоря считать полилинию набором отрезков и дуг)
1. Регулярное разбиение - это фактически только определение шага, дельт по осям координат, на которые условно разбивается пространство. Индексом ячейки такого разбиения могут быть сами координаты x, y, z угла ячейки или некие номера ячеек.
2. Регулярное разбиение обладает возможностями дерева, т.к. в любой момент для любой точки можно рассматривать прямоугольник (объем) любой суммы смежных ячеек. Причем, поскольку все ячейки равноценны, в рассмотрение не попадет сильно избыточное число примитивов, как было бы в дереве, если нужный объем захватывает соседние "ветви".
3. Доступ к нужным площадям (объемам) при регулярном разбиении много проще - не нужно просматривать списки габаритов узлов (нод). Сам индекс ячейки указывает на определенную часть пространства.
Т.е. никакого "разбиения", определения, описания ячеек не производится - определяется только попадание габаритов примитивов в ячейки как проверка на > < координат, кратных размерам ячеек. Нет необходимости и хранить описания самих ячеек. Достаточно хранить только не пустые списки элементов ячеек в порядке возрастания индекса.
4. При этом, регулярное разбиение позволяет считать пространство разбиения бесконечным и в +, и в -. Если принять за начало 0,0,0, и допустить индексы не только положительные, но и отрицательные. Т.е. изменение габаритов файлов не требует перестроения разбиения в целом.
5. Регулярное разбиение безусловно - проверка идет только на пересечение габаритов примитивов с ячейкой, т.е. не тратится время на анализ и принятие решений о том, в какой узел что помещать, как элементы относятся к другим элементам. Т.е. задачи стараться "вписать" примитивы нет, и "другие примитивы" не будут ничего "портить". Главное - подобрать оптимальный размер ячеек разбиения.

Резервы:
1. Уже писал, что можно попробовать уточнять положение примитивов в ячейках за счет проверки попадания в них габаритов сегментов примитивов. Причем, делать это можно не сразу, не для всех примитивов, а по мере их обработки.
2. Можно попробовать хранить списки не только примитивов в ячейках, но и списки ячеек, в которые попадают примитивы. Возможно, что это еще упростило бы обработку. Т.е., рассматривая любой примитив, можно было бы сразу знать о других примитивах, находящихся в "его" ячейках. Причем, "его" ячейки в общем случае не образуют прямоугольник, т.е. не захватятся избыточные примитивы.
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 23.09.2013, 21:35
#90
trir


 
Регистрация: 18.12.2010
Сообщений: 2,431


Пурга, читай книжки ISBN: 978-5-8459-1744-7 (рус.)

Update:
1. Сложность поиска в списке O(n) - где n - количество элементов. Сложность поиска в дереве O(h) - где h - высота дерева. Смотри у zamtmn
Цитата:
Max tree depth: 16
Цитата:
Total entities: 20000
- Почувствуй разницу

Последний раз редактировалось trir, 23.09.2013 в 21:52.
trir вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 23.09.2013, 22:13
#91
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


Имхо регулярное разбиение имеет приемущество только для постоянно меняющихся данных (желательно специально подготовленных) за счет возможно более быстрого "построения", ито это нужно провеить экспериментально или почитать книжки
>>а сухой остаток что-то жидковат
Нифигасебе)) показано и как просто примитивы перебирать, и умные ссылки даны на всякие пространственные хитрости, и есть пример не очень умной реализации - всё разжевано, что еще надо то? Осталось только уволить програмиста и самому за реализацию взяться))
1 - это главный минус - размер ячейки фиксирован - мелкие детализованные учстки чертежа окажутся в 1-2-3-4 "ячейках". Т.е. повышение детализации фрагмента чертежа не вызывает повышение детализации сетки. В случае даже самого простого бинарного дерева разбиение автоматически повышает детализацию на насыщенных участках чертежа.
2 - достоинство дерева при отбраковке вышестоящей ноды автоматом отбраковываются все нижестоящие. т.е. если мы ткнули мимо чертежа, тест корневой ноды сразу нам об этом скажет, а в сетке что об этом скажет? перебор всех ячеек?
3 - этот момент полностью аналогичен и в дереве и в сетке, т.к. разбивка хочешь нехочешь строится в габаритах чертежа, а не в абсолютных координатах в "бесконечном" пространстве
4 - нет, иначе придется хранить бесконечное количество пустых ячеек, для сохранения доступа к ним по индексу, см. п.3
5 - непонял. имхо все также как и с деревом, идеально выбрать сетку не выйдет и будет куча примитивов которые сидят в куче ячеек

trir
>>Сложность поиска в списке O(n) - где n - количество элементов. Сложность поиска в дереве O(h) - где h - высота дерева. Смотри у zamtmn
Насколько я понимаю АлексЮстасу хочет сказать что в его сетке сложность будет O(1), но это действительно пурга, т.к. идеально разбить не подготовленные специально данные не получится.

Последний раз редактировалось zamtmn, 23.09.2013 в 22:40.
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 23.09.2013, 23:39
#92
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,837


Цитата:
Сообщение от АлексЮстасу Посмотреть сообщение
В теме написано аж на пять страниц, а сухой остаток что-то жидковат
А по моему все необходимое для реализации, есть уже на 1 странице, разжеванно до уровня птушника на 2 и представленна реализация на 3. Вы, наверное, ожидали к 5 странице готовый инсталятор? По моему Вы, на пару со своим программистом, уже должны zamtmn'у как земля колхозу, а Вам "остаток жидковат", да реализация неэффективна.
Цитата:
Все-таки что-нибудь скажете про мой алгоритм оптимизации регулярным разделением файла?
Ваш "алгоритм" будет эффективен только на специально приготовленных для него чертежах. Перед изобретением велосипедов, рекомендую ознакомиться с механизмами в используемых моделях. Если он Вам так нравиться можете кататься на нем, но эффективней от этого он не станет. Короче учиться, учиться и еще раз учиться.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 24.09.2013, 21:10
#93
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


Цитата:
Сообщение от trir Посмотреть сообщение
Пурга, читай книжки ISBN: 978-5-8459-1744-7 (рус.)
Цитата:
Сообщение от Дима_ Посмотреть сообщение
А по моему все необходимое для реализации, есть уже на 1 странице, разжеванно до уровня птушника на 2 и представленна реализация на 3. Вы, наверное, ожидали к 5 странице готовый инсталятор? По моему Вы, на пару со своим программистом, уже должны zamtmn'у как земля колхозу, а Вам "остаток жидковат", да реализация неэффективна.
Цитата:
Сообщение от zamtmn Посмотреть сообщение
>>а сухой остаток что-то жидковат
Нифигасебе)) показано и как просто примитивы перебирать, и умные ссылки даны на всякие пространственные хитрости, и есть пример не очень умной реализации - всё разжевано, что еще надо то? Осталось только уволить програмиста и самому за реализацию взяться))
Посоветованные книги, упомянутые алгоритмы, общие идеи, реализация zamtmn - это очень здорово. За все это однозначное, не из вежливости, спасибо!
Но совершенно непонятно, что из этого практически применимо, эффективно для специфики Автокада, при программировании под Автокад, для нашего вида данных? Какой из видов деревьев для автокадовских данных эффективнее, в каких случаях, какие из деревьев, как лучше реализовать на том-другом языке, какой это может дать, дало реальный результат?
zamtmn, результаты Вашей оптимизации впечатляют, бьют наповал, но что из этого выйдет в Автокаде? Впечатляет фантастическая скорость просмотра примитивов hwd, но неясно, как это помогает анализу геометрических отношений примитивов?
Кроме этих двух реальных, реализованных примеров (не в Автокаде, не для анализа геометрии), получается, ничего не абстрактно-теоретичекого нет или великая тайна.
Ну, значит, так.
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 24.09.2013, 21:26
#94
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,837


Цитата:
Сообщение от АлексЮстасу Посмотреть сообщение
(не в Автокаде, не для анализа геометрии), получается, ничего не абстрактно-теоретичекого
Вы уверены, что понимаете о чем Вам пишут, а где и для чего по Вашему?? Если Вам этого мало - то просто не пытайтесь этим заниматься - это, так сказать, не Ваше...
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 24.09.2013, 21:57
#95
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


>>но что из этого выйдет в Автокаде?
Должно получиться гораздо лучше
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Автор темы   Непрочитано 25.09.2013, 20:48
#96
АлексЮстасу

топограф, технолог
 
Регистрация: 24.05.2009
Москва
Сообщений: 2,551


Цитата:
Сообщение от trir Посмотреть сообщение
regular.dxf
- 383 секунды, key_buffer_size = 104857600
regular.dxf я до сих пор не проверял:
- Autocad Map 3D - Drawing cleanup - Break intersections сделало на средней машине за примерно 3.5 секунды!
- Лисп BreakObjects - на двадцатой, примерно, минуте я остановил процесс.
Получается, что Autocad Map 3D для своих действий оптимизацию очень даже применяет.

И про FlashPolygons от Delicad - сделал из всех пересечений элементов в меньшем nonregular2.dxf полигоны за 30 секунд.
Цитата:
Выберите объекты: Противоположный угол: найдено: 1172
Выберите объекты:
>> Processing, please wait ...
>> 20896 Internal polylines created in layer 'internal_polylines'
>> 7 External polylines created in layer 'external_polylines'
>> 0 Polylines with area under 0.000 ignored.
Похоже, что при создании пересечений есть еще одна задача для оптимизации - число получаемых при пересечениях примитивов оч. большое, миллионы. В nonregular.dxf пересечений, наверное, по 200 на линию.Вероятно, Drawing cleanup и лисп BreakObjects на создании этих миллионов примитивов и зависают.
Как бы сделать создание новых примитивов из пересечений, чтобы и ресурсов хватало, и скорость была высокой? Общие подходы можете посоветовать?
АлексЮстасу вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 25.09.2013, 23:14
#97
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,362
Отправить сообщение для zamtmn с помощью ICQ


>>Общие подходы можете посоветовать?
x86_64, максимум ОЗУ, толстый свап
zamtmn вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 26.09.2013, 10:24
#98
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 1,440


Цитата:
Сообщение от АлексЮстасу Посмотреть сообщение
Общие подходы можете посоветовать?
1. Не сравнивать производительность компилируемых и скриптовых ЯП
2. Использовать компилируемые ЯП
Boxa вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 26.09.2013, 14:32
#99
Мансур

Инженер САПР
 
Регистрация: 12.11.2004
Тюмень
Сообщений: 36
Отправить сообщение для Мансур с помощью ICQ


Извиняюсь, что встреваю в мудрые разговоры.
Раз дело касается AutoCAD, то и используйте его возможности.
Как, например, здесь: объединение большого количества отрезков.
Волшебная функция (ssget "_C" p1 p2) наверняка уже тыщу раз оптимизирована разработчиками, берите и используйте - тогда даже на обыкновенном autolisp все шустро просчитывается. Если непонятно: берете примитив, получаете его bounding box, по ним ssget - получаете (обычно) небольшой набор, по нему уже тупо перебором проверили реальные пересечения. И не надо никакой мороки со всякими индексами, ибо индексы уже есть в самом автокаде.
Мансур вне форума вставить имя Обратить внимание модератора на это сообщение  
 
Непрочитано 26.09.2013, 15:27
#100
bargool


 
Регистрация: 16.08.2006
Санкт-Петербург
Сообщений: 497
Отправить сообщение для bargool с помощью ICQ


Цитата:
Сообщение от Мансур Посмотреть сообщение
ssget
Поправьте меня, если я ошибаюсь: эта волшебная функция требует, что бы данный прямоугольник был на экране. Т.е. либо скакать по всему чертежу, либо масштабировать, что бы весь чертёж сразу был на экране.
При самостоятельной обработке я могу работать даже без открытия чертежа (открывая только базу данных), что гораздо быстрее при пакетной обработке, скажем.
Да и в целях тестируемости лучше изолировать код, работающий непосредственно с автокадом как можно дальше (т.е. выделить зависимости от автокада в как можно меньшее кол-во классов, и только изредка их использовать)
Так что оба метода имеют право на жизнь, у каждого своё предназначение.
Аналог ssget в .net данном случае будет метод Editor.SelectCrossingPolygon
__________________
Алексей
bargool вне форума вставить имя Обратить внимание модератора на это сообщение  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Оптимизация обработки большого числа элементов

Инженерные консультации
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Жилые и общественные здания: краткий справочник инженера-конструктора. Под ред. Ю.А. Дыховичного и В.И. Колчунова. 2011 (Впечатления и отзывы). Armin Поиск литературы, чертежей, моделей и прочих материалов 17 22.08.2017 16:55
Документация Проектировщику на Torrents DEM Разное 251 23.06.2016 11:59
Порекомендуйте литературу для повышения квалификации(грунты, геотехника) acid Поиск литературы, чертежей, моделей и прочих материалов 6 13.05.2015 22:14
Случайный эксцентриситет p_sh Прочее. Архитектура и строительство 14 22.07.2009 11:32
Защита от распространения большого числа dwg E.D. AutoCAD 24 21.11.2008 09:02

|| Главная || Каталог САПР || Тендеры || Публикации || Объявления || Биржа труда || Download || Галерея ||
|| Библиотека || Кунсткамера || Каталог предприятий || Контакты || Файлообменник || Блоги ||


Размещение рекламы