[CDR 2017-2021] Влияние количества макросов на скорость работы приложения

  • Автор темы Автор темы iKoolk
  • Дата начала Дата начала

iKoolk

Участник
Топикстартер
Сообщения
217
Реакции
11
Бодрый день, коллеги.
Изучал ли кто влияние количества макросов на скорость работы приложения, а также зависимость скорости от количества выведенных иконок на панельки. Если да, поделитесь цифрами. Есть ощущение, что все-таки влияет.
 
На скорость загрузки немного влияет общее количество; на скорость работы, скорее всего, влияет количество хукнутых обработчиков всевозможных событий. А зачем все-все-все выводить? Это отвлекает.
 
Нет, в моем случае макросы простейшие, решающие рутину, за действиями пользователя не следят, на события не реагируют, действуют когда попросят и выполнив задачу благополучно завершаются. А вывожу, потому что в компании 9 дизайнеров, почти все девчонки и я заметил, что если им кнопочку сделать они активно и благодарно пользуются, если хоткей - то благополучно забывают. Висячая постоянно форма займет место на экране, да и возможно ресурсы, хотя конечно несущественные, а два клика, например UserMenu и в нем пункты это больше чем один.
 
Ну если вопрос был в этом, лично я не могу придумать рационального обьяснения тому, как наличие дополнительной панели на экране может существенно отьедать на себя ресурсы системы.
Возможно, чтобы ответить на данный вопрос нужно какое то время пожить в Индии, где я ни разу не был?
 
Ну перейдем к теории. Если присунуть .gms работающему корелу, то его макросы будут недоступны. Перезапускаем - добро пожаловать. Что если корел при запуске не просто получает знания о существующих модулях, а что-то куда-то еще подгружает. Далее: работа с Tools-Options-Кастомизация. Вынос любого элемента наружу это прям корел вначале в задумчивость вводит, особенно, если tool tips присутствует. то есть для корела это прям событие! этим прям заняться надо!
 
Бррр
Логика ваших рассуждений выглядит настолько странно, что я прям даже сперва растерялся что сказать.
А что странного в том, что корел опрашивает каталог GMS при своей загрузке? Или, по вашему, он в непрерывном режиме должен его сканировать некоей активной задачей? Таки да, это сильно жрало системные ресурсы, если б было правдой :D
Про погружение чего-то куда-то и вынос чего-то куда-то я, признаться, вообще не понял, каким боком это к пожиранию ресурсов относится, можно эти две мысли поподробнее? ;)
 
Про GMS. Я построил на предприятии такую систему: пишу макрос, или исправляю прошлый, добавляю кнопку на панель или хоткей, сохраняю рабочее пространство. Потом локально на машинах заменяю свой .gms и переимпортирую рабочее пространство. (про Symbolic Link прошу мне не рассказывать). Таким образом на всех машинах единообоазие и по макросам и по рабочему пространству. Подмечено, что если заменить .gms при запущенном кореле, то новый добавленный макрос не будет работать, отсюда вопрос: я не прошу постоянно GMS опрашивать, но вот появилась попытка запустить макрос к которому, как я понимаю, прописан прямой путь - модуль, процедура, так почему бы сейчас не переопросить GMS? типа есть чё? вот поэтому я думаю, что корел при загрузке что-то у себя создает связанное с макросами.
По второй мысли. Наверняка Вы создавали CommandsBar и наполняли его командами, так вот при наполнении командами корел прям тупит. Встаем в коммандсе на процедуру, которую хотим поместить на Бар и ждем несколько секунд, пока корел позволит это делать. Так как у меня уже давно не было чистого корела (рабочее пространство с моими любимцами мигрирует от версии к версии), то то ли мне кажется, то ли в самом деле, когда я обрастаю большим количеством макросов, вот эта пауза между тем, когда я встал на команду и когда я могу утащить ее на Бар - растет. Поэтому я думаю, что у корела здесь тоже какая-то нужда и, следовательно, как-ть нерационально построенно, потому что я с Вами согласен - страдать здесь софтинке совершенно не из-за чего, но все же что-то есть.
 
я думаю, что корел при загрузке что-то у себя создает связанное с макросами.
Ну так разве это не очевидно? Они конечно могли переопрашивать каталог макросов при каждом вызове редактора, однако, часть событий обрабатывается макросами именно при загрузке файлов или корела поэтому самое резонное и все макросы опрашивать в этот момент. Соответственно, если макросов много то и опрашивать будет их чуть дольше, все это вполне логично.
По второй мысли. Наверняка Вы создавали CommandsBar и наполняли его командами, так вот при наполнении командами корел прям тупит. Встаем в коммандсе на процедуру, которую хотим поместить на Бар и ждем несколько секунд, пока корел позволит это делать.
Ну не оптимизировали они процесс добавления, ну и что? Это ж разовая операция, которая выполняется только в момент добавления макроса на панель, а даже не каждый раз когда к этому макросу обращение идет. В принципе да, чем больше обработчиков тем медленнее вызывается каждый из них при прямом вызове, однако, замедление должно быть столь незначительно, что даже не должно быть заметно глазу, в самом деле, там же не тысячи или сотни обработчиков, а максимум, десятки