Можно ли ускорить выполнение программы VBA (Страница 1 из 3)

.NET ? Это по-моему тот же VBA, только по-другому. Я прав? А основа программирования ObjectARX на каком языке программирования?

VB, VBA, Delphy работают через COM. ...COM это "медленно"(ест-но относительно большого количества создаваемых объектов) Т.е. у тебя скорее всего не сама логика программы медленно работает, а присутствует "медленная" связь с Автокадом.
Перепишешь программу на
VB.NET, c#.NET, и т.д. через (основные библиотеки acmgd.dll и acdbmgd.dll ), уберешь "медленную" связь с автокадом.

....а вообще, чтобы точно понять, что у тебя тормозит работу... вставь таймеры на каждую операцию.
В C# это делается так:

using System.Diagnostics;
Stopwatch swatch = new Stopwatch();
swatch.Start(); // старт
....твоя операция
swatch.Stop();
MessageBox.Show("Время выполнения: " + swatch.ElapsedMilliseconds);

...получишь например такие результаты
1. Чтение файла в массив 30 сек
2. Поиск в массиве необходимых данных 10 минут
3. Связывание с автокадом и построение 10 минут

...уже поймешь что 1 пункт хоть заоптимизируйся, много не выйграешь, а с 2,3 можно поколдовать.
...если перейдешь на NET, ObjectARX, ты воздействуешь только на 3 пункт ;)

Я и сейчас знаю что у меня "медленный" блок видимо связь с автокадом. Смысл этой связи вот такой:
1. предварительно прочитан объем данных в массив - набор точек NomerPoint,X,Y,H,kod
2. на чертеж вынесены индексы этого массива
3. вокруг каждой расчетной точки в радиусе R определены и отсортированы другие точки посредством SelectionSet - это есть связь с ACAD.
Чисто математически мне кажется это долго делать, если объем данных большой (более 10-15 тыс.точек), потому что нужно сначала рассчитать полярные расстояния от расчетной точки до всех остальных и отбросить те, расстояние до которых более R. На больших объемах данных это сильно тормозит процесс определения номеров точек в радиусе R. Это проверено! Через SelectionSet сейчас это реально быстрее. Но все равно данных 25 тыс.точек -> время работы программы 1 ч 20 мин. Хотелось бы побыстрее.
Может у кого есть математический алгоритм, позволяющий значительно ускорить процесс выбора группы точек вокруг каждой расчетной на расстоянии R?
4. выполнены определенные вычисления
5. построен чертеж - не очень сильно тормозит на фоне других процедур. В ACAD выведено 175 тыс.примитивов
6. создано несколько текстовых файлов

А можно ссылку на программу и документацию VB.NET?

Я уже давно отказался от решения задачи в лоб и за 5 лет колдовства над программой добился таких результатов (1 ч 20 мин) с постепенным усложнением и наворачиванием. На первых моих алгоритмах мне кажется на это ушло бы не менее 5 часов.
В некоторых случаях пришлось применять алгоритмы быстрой сортировки, написанные изначально для линейных массивов, к прямоугольным массивам и т.д. Вот теперь я вновь пытаюсь ускорить вычислительный блок (пункт 3).

Хочу сказать что все объекты для которых я строю чертежи ACAD - это в основном линейные объекты - железнодорожные станции и железнодорожные перегоны, а расстояние R=250 м - это максимальная величина габарита от съемочной точки до пути (ближайшего или любого другого). Координаты точек получены в результате геодезической съемки полосы вдоль ж.д.путей в пределах 100-200 м в обе стороны.

Бесплатная среда разработки
http://www.microsoft.com/express/Downloads/
ObjectARX...внутри еще и для .NET документация и примеры
http://usa.autodesk.com/adsk/servlet/it … ;id=785550
Подробности смотри в разделе форума .NET

1. Если смотреть по перспективности .NET и ObjectARX предпочтительнее, чем VBA и LISP.
2. По скорости отрисовки в AutoCAD и работы с БД чертежа....тоже .NET и ObjectARX. Но стоит учитывать задачу например вставка форматок и на LISP не тормозит....переписывать из-за скорости на .NET смысла нет). В конкретно обсуждаемой задаче смысл наверно есть)
3. По скорости расчетов, логических операций, работе с файлами, массивами C++,.NET,VBA примерно одинаковы. Стоит избегать "ГОВНОКОД", который из С++ может сделать черепаху, более медленную чем LISP. А также стоит выбирать правильные алгоритмы, массивы, принципы буферизации и т.д.
4. Всегда учитывайте время разработки и обучения, т.к. это лимитированный ресурс.

Нет. Особенно это касается расчетов. Чтение данных из чертежа может быть примерно одинаковым, хотя VBA наиболее медленный в силу общения с AutoCAD через COM-интерфейс.

Вечером размещу информацию с курсов по ObjectARX...там есть некоторое сравнение по скорости VB, VBA, Lisp, C#, ObjectARX. Но хотелось бы побольше информации.

У меня когда-то была задача: выбрать определенные объекты внутри прямоугольной полилинии. Использовал метод select (в сущности, классика жанра):

' Add all object to the selection set that lie within a crossing of (28,17,0) and
    ' (-3.3, -3.6,0) 
    Dim mode As Integer
    Dim corner1(0 To 2) As Double
    Dim corner2(0 To 2) As Double
    
    mode = acSelectionSetCrossing
    corner1(0) = 28: corner1(1) = 17: corner1(2) = 0
    corner2(0) = -3.3: corner2(1) = -3.6: corner2(2) = 0
    - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ssetObj.Select mode, corner1, corner2, intDXF, FilterValue

Владимир, может и тебе стоит использовать квадрат вокруг расчетной точки, а не окружность?

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

Я это понимаю, только пока не нашел быстрого алгоритма, потому и справшиваю на форуме

По-моему это слишком просто - простой перебор, а, значит, и слишком долго. Для каждой точки найти список точек, находящихся в квадрате LxL в первом проходе, а заетм во втором проходе поискать нужный список. Считаем количество операций только по первому проходу. Общий объем точек 25000 шт. Nопер1 = 25000 х 25000 = 625 млн.опер. Если добавим второй проход (1-я выборка примерно 200 шт в квадрате LxL), то Nопер2 = 625 млн.опер. x 200 = 125 млрд.опер. При частоте процессора 2.33 ГГц это составит 53 сек только на один перебор значений циклов. Если добавить всю необходимую математику, то будет наверное раз в 100 больше, т.е. 1,5 часа. Может быть я ошибаюсь. Если у вас есть такая статистика подскажите, далеко ли я от истины.

Мне нужно вокруг КАЖДОЙ из 25000 точек найти точки в радиусе R метров. Их примерное количество в этом радиусе будет около 200 шт.

Спасибо попробую.