На ней располагается 212 графических объектов различных типов: задвижки разных видов, регуляторы, насосы, цифровые индикаторы.
Во-первых, мнемосхема очень долго грузится в редакторе (сегодня специально замерял - 10 минут 50 секунд на CeleronD 3.06 GHz). Во-вторых, столько же она грузится и в МРВ, а при работе постоянно хавает 60-80% процессороного времени (ничего особо не делая).
Опыты выявили прямую зависимость между количеством графических объектов на мнемосхеме и скоростью загрузки/нагрузкой на процессор(при удалении объектов вообще падает до 0-6%).
Кроме того, замечено, что если последней редактировалась не данная мнемосхема, а какая-либо другая - с малым количеством элементов, - то процесс загрузки проекта в МРВ проходит быстро (исчисляется секундами), но на загрузку процессора не влияет.
Хотелось бы разобраться в данной проблеме, поскольку эксплуатировать в таком виде не представляется возможным (загрузка процессора слишком велика и не оправдана).
И еще, если проблема будет локализована, стоит ли мне продолжать в том же духе с надеждой на скорое исправление, или разгруппировывать объекты, что практически смерти подобно (за то малое время, что у меня есть)?
Сообщения / Posts 340 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Использование большого числа графических объектов, конечно, не самый лучший способ. Где можно лучше заменить его на стандартные элементы.
В релизе 6.06 значительно улучшится работа с графическими объектами в реальном времени. При работе в инструментальной среде улучшений скорее всего не будет.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
Использование большого числа графических элементов обусловлено в том числе и тем, что отсутствует механизм группировки графических элементов в редакторе, ведь даже простая статическая задвижка состоит из 2 элементов, а есть объекты, состоящие и из 3-5 элементов. И неудобно для размножения выделять их все, гораздо удобнее, чтоб это был один сгруппированый объект.
P.S. ...не совсем понятно, чем может заниматься достаточно мощный процессор на протяжении 10 минут со 100% загрузкой при открытии мнемосхемы...
Сообщения / Posts 340 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Занимается проверкой всевозможных связей. На это уходит значительное количество времени
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ShuraX (TM_Prof)
Forum Member / Участник форума
Участник № / Member № 3130
отправлено / posted
На счет объектов и динамизации графики могу добавить, что заметил следующее: я так же использую на экранах одни объекты (с практической т.з. и ООП предпочтительный вариант [правда в ТМ со своими особенностями ] ) Так вот: если одновременно использовать статическую динамизацию и видеоклипы, то тормоза на порядок увеличиваются нежели без видеоклипов (даже если используется один видеоклип). Так что пришлось полностью отказаться от использования видеоклипов. Значительно снизить тормоза удается если полностью перейти на 2D объекты и не использовать 3D объекты (упаси боже еще со всякими текстурами, материалами, прозрачностью, одно под другое подкладывать и т.п.), что планирую и сделать (пока все в 3D сделал по отсутствию опыта работы с ТМ6). И поему субъективному мнению (после прокрутке на МРВ) визуально "плоская" мнемосхема воспринимается лучше, чем "объемная" (это подтвержают и операторы). Для снижения тормозов можно еще всю статику в файлик запихнуть и использовать его как подложку экрана мнемосхемы.
quote:Отправитель / Originally posted by AdAstra Technical Support: Использование большого числа графических объектов, конечно, не самый лучший способ. Где можно лучше заменить его на стандартные элементы.
Зачем они тогда нужны если их использовать в полной мере не удается?! И, действительно, отсутствие группировки ГЭ на мнемосхеме (как это было в ТМ5) делает неудобной процедуру "лучше заменить его на стандартные элементы". Я так думаю, отсутствие данной возможности как раз и предполагало восполнить использованием объектов, что в принципе правильно с т.з. ООП, а главное ОЧЕНЬ удобно(!), вот только упирается в выше приведенную цитату.
отправлено / posted
Основное значение надо придать словосочитанию "Использование большого числа", в данном конкретном примере их было на одном экране около 200. При этом при тестировании на выходящем в скором времени релизе работа с этим экраном никаких проблем не создавала. Загрузка процессора была в районе 10-15%.
ShuraX (TM_Prof)
Forum Member / Участник форума
Участник № / Member № 3130
отправлено / posted
Именно про "Использование большого числа" и думал . У меня на одном экране сейчас также порядка 200 объектов, в каждом от 4 до 7-8 аргументов. В ИС загружается за 1-1,5 минуты. Правда пока аргументы экрана не привязаны к каналам. На аналогичном проекте у коллеги (часть экранов у него привязаны уже) на МРВ загрузка процессора в среднем 70-75%.
SerchenyaN
Forum Member / Участник форума
Участник № / Member № 2877
отправлено / posted
Новый релиз - это всё конечно здорово, но что нам делать с уже купленным 6.05.1? в утиль? деньги-то уплачены... Или есть возможность бесплатно обновить профессиональную версию?
quote:AdAstra Technical Support Трудности возникали при загрузке (10-15 мин) данного экрана в ИС, что в принципе не критично.
Удовольствия мало доставляет ждать открытия экрана 15 минут, а потом после кое-какого редактирования ждать ещё +15 минут, чтобы проверить работу в профайлере. И чем дальше, тем хуже.
Теперь о МРВ и NLL (которые тоже приобретены). При запуске МРВ или NLL загрузка в нашем случае 2-х ядерного процессора не выходит за пределы 50% (т.е. одно ядро на 100%), что в принципе допустимо, но 15 минут ожиданий запуска в процессе пусконаладочных работ - это чрезвычайно раздрожающий и отнимающий много времени фактор.
quote: AdAstra Technical Support Занимается проверкой всевозможных связей. На это уходит значительное количество времени
Этим же он занимаеться и при запуске МРВ? Тогда может подскажете возможность хоть каким-то образом сократить время запуска. У нас один из NLL вообще планировался как вспомогательный, который будет запускаться лишь по мере необходимости. И компьютер будет работать не круглосуточно. А теперь выходит, что пользователь должен будет каждый раз по 15 минут ждать загрузки, а потом и ещё минут 5 старта? В таком виде система будет приносить больше неудобства и негативных эмоций при эксплуатации, нежели пользы. Подскажите, пожалуйста, может можно как-то обойти проблему?
Сообщения / Posts 47 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
отправлено / posted
Давайте дождемся нового релиза. Он будет работать примерно в 3-4 раза быстрее. Обновить Вы его сможете бесплатно на нашем сайте.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
SerchenyaN
Forum Member / Участник форума
Участник № / Member № 2877
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
А может есть бета-версия? Хотя бы МРВ? А то 15 августа на объект ехать и мне кажется, нас там не похвалят за такое быстродействие.
Сообщения / Posts 340 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Возможность участия в бета-тестировании обсуждается индивидуально. Заявки можно отсылать на адрес hotline@adastra.ru
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[Улыбка / Smile]](smile.gif)
] ) Так вот: если одновременно использовать статическую динамизацию и видеоклипы, то тормоза на порядок увеличиваются нежели без видеоклипов (даже если используется один видеоклип). Так что пришлось полностью отказаться от использования видеоклипов. 
