[vosh]

Добрый!
Снова за знаниями, вопроса два, первый основной.
Скомпилировал в визуал лисп редакторе программу, размер конечно у нее сократился, но прироста производительности при перелопачивании большого количества примитивов не заметил, собсна вопрос так и должно быть и если да то есть ли альтернативы по ускорению?

Второй вопрос (можно не отвечать ) - В процессе написания замусорил программу переменными, есть ли способ получить список их автоматически?

[Александр Ривилис]

вопрос так и должно быть

Может да, а может быть и нет. Это зависит от алгоритма функции.

и если да то есть ли альтернативы по ускорению?

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

есть ли способ получить список их автоматически

Так при компиляции VisualLisp вроде создает список локальных переменных.

[CB]

По второму вопросу можно сделать так:
1. Создаем глобальную переменную
(setq *global-var* (atoms-family 0))
2. Загружаем выполняемую программу и запускаем ее.
3. Создаем новую глобальную переменную
(setq *global-var-new* (atoms-family 0))
4. Выполняем код:

Код:

[Выделить все]

(foreach item *global-var* (setq *global-var-new* (vl-remove item *global-var-new*)))

Итог - список функций и переменных, оставшихся после выполнения функции + *global-var*.

[Елпанов Евгений]

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

Все зависит от того, как написана программа. По моим личным тестам, программа ускоряется в 3 - 10 раз после компиляции. Но все зависит от самого кода, его можно написать и так, что никакой компилятор не разберется, как его можно ускорить... И еще, каждое обращение к командной строке, дает существенное замедление. Если все делать через ком строку - то компиляция вообще не даст прироста производительности.
PS. из моих наблюдений, самые большие тормоза в программе:
1. обращение к ком строке
2. (gc)
3. повторная загрузка, уже загруженных программ
3. режим отлова и/или игнорирования ошибок
4. множественные проверки одного и того же
5. работа с примитивами - т.е. не съем данных о геометрии, вычисление и отрисовка по результатам, а именно последовательная работа с примитивами, их преобразование, дополнительные построения и.т.д...
PS. написал список не учитывая важность пунктов, но считаю, что это основные моменты, которые тормозят больше всего...

[Alaspher]

Получить список глобальных переменных (валидация исходника) в редакторе vlide - Ctrl+Alt+C

[Makswell]

Также можно посмотреть глобальные переменные и их значения в окне вставки поля в текст (Прочее->LispVariable).

[vosh]

2 CB: таким образом, если я все правильно понял, я получу список глобальных переменных, которые я ввел своей прогой, у меня проблема наоборот в заголовке слишком много зарезервировано переменных, и надо проредить, узнав какие из них действительно используются.
2 all: По второму вопросу сегодня вечером разбираццо буду.
По первому, сегодня проэксперементирую наверняка, задам долгую множественную операцию и сравню результаты, о чем отпишусь.
ps : коммандную строку не использую принципиально, помоему на ней не сделать "быстрых" программ.
ps2: сделал один важный вывод: если изначально знаешь, что в будущем быстрота работы программы будет принципиальным вопросом, то лучше вводить побольше переменных и не проделывать многократно одно и то же действие, а присваивать значение переменной и работать уже с ней.

[Alaspher]

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

Удали все перечисленные, как локальные, нажми Ctrl+Alt+C, скопипасть список переменных из строки, в которой будут перечисленны глобальные переменные. Одно НО - если используются команды и в них задействована pause, то её из списка локальных надо удалить, иначе будут глюки.

Сообщение от vosh если изначально знаешь, что в будущем быстрота работы программы будет принципиальным вопросом, то лучше вводить побольше переменных и не проделывать многократно одно и то же действие, а присваивать значение переменной и работать уже с ней.

Совсем не факт - повторные вычисления, конечно нежелательны, но и само присвоение/чтение отнимает время. Лучше всего, когда результат вычислений функции попадает на вход другой функции, но и тут фанатизм неполезен.

[Елпанов Евгений]

Большая часть моих программ, относится к ресурсоемким и требует значительного времени на выполнение. После написания кода и его оценки по скорости выполнения, если она не устраивает, я начинаю вычислять самые медленные участки кода и переписываю их несколько раз, различными алгоритмами или подходами, постоянно сравнивая скорость выполнения. Оптимизация программ - самостоятельная тема, которой можно заниматься без конца - нет предела совершенству...
PS. Несколько раз, пытался написать список требований к коду, используя который, можно писать быстрые программы. Время объяснило мне, что в автолиспе, не может быть критических требований, сложнее, чем просто опрятный и оптимальный код - уловки из одной программы, могут не помочь в другой...

[Евгений А.]

Елпанов Евгений Я бы ещё в ваш список воткнул бы функцию entget, особенно для ACIS объектов, результат этой функции лучше один раз записать в переменную (как советует vosh), а то у меня в прогах эта командой и есть тот самый предел совершенства