Сохранение проекта

[Cat]

Доброго времени суток!
Товарищи инженеры, проблема такая: проект разросся с n файлов до n^10 файлов, при этом еще и GUI довольно сложный. Сохранение, как проекта так и его составных частей, особенно с GUI, происходит медленно, даже очееень мееедленно, иногда даже диспетчер пишет, "объект не отвечает", и через некоторое время все отмирает и сохраняется. Кто сталкивался с таким, как решили?

[dadreamer]

А по одной тоже медленно сохраняет? Железо какое используется? Может быть, произвести апгрейд как софта, так и hardware части, например, заменить IDE/SATA на SSD?..

[Borjomy_1]

Сколько файлов в проекте? 100 или 10000?
Медленно может быть из-за
1. большого количества взаимосвязей в программе, из-за чего компиляция с большой рекурсией. Как признак - подтормаживание при внесении изменений в блок-диаграмму.
2. Большого объема выделенных данных в VI, из-за чего большая часть лежит в свопе.
3. Большого объема "забытых" данных из-за использования Probe с классами или массивами сложных кластеров.
Смотрите в диспетчере задач разницу между столбцом "Память" и "Выделенная память". Все тормоза возникают при компиляции и при выгрузке из свопа (Выделенная память) в оперативку (Память)

[AndreyDmitriev]

Доброго времени суток!
Товарищи инженеры, проблема такая: проект разросся с n файлов до n^10 файлов, при этом еще и GUI довольно сложный. Сохранение, как проекта так и его составных частей, особенно с GUI, происходит медленно, даже очееень мееедленно, иногда даже диспетчер пишет, "объект не отвечает", и через некоторое время все отмирает и сохраняется. Кто сталкивался с таким, как решили?

Пришла пора сделать функциональную декомпозицию. Грубо говоря - вам надо разбить проект на части и каждую часть сделать отдельным проектом. Обычно архитектура плагинов помогает в такой ситуации. Даже интерфейс можно разбить на части и грузить всё в панели.
В настоящий момент у меня в проекте 5340 файлов, но в самом большом модуле - только 150. Управляет всем этим ядро из 463 файлов (это если только *.vi и *.ctl считать). Особых проблем нет (ну разве что при переходе на новую версию лабвью - за время масс-компиляции можно успеть пообедать)

[Vitekkz88]

В настоящий момент у меня в проекте 5340 файлов

Батюшки-свет...это что же за проекты за такие? Или там в отдельные subVI выносится всё, что более 3-х стандартных LabVIEW-шных .vi?

[AndreyDmitriev]

В настоящий момент у меня в проекте 5340 файлов

Батюшки-свет...это что же за проекты за такие? Или там в отдельные subVI выносится всё, что более 3-х стандартных LabVIEW-шных .vi?

Нет, конечно, не выносится. В основном они вписываются в экран, но некоторые требуют рефакторинга и занимают три-четыре экрана по вертикали.
Это модульная программа для систем рентгеновского неразрушающего контроля. Многим заказчикам нужно что-то особенное, системы тоже сильно разные, разные детекторы. В основном машинное зрение, включая томографию, но есть и автоматика. Сейчас насчитывается 270 модулей, так что в среднем это двадцать VI на проект всего. Три человека, восемь лет работы - в общем-то не так много. Архитектура получилась довольно удачная - мы можем очень быстро собрать практически всё, что угодно из готовых кирпичиков и добавить практически любой функционал. Понятно, что заказчик не получает все модули - типичная система насчитывает где-то 30-50 плагинов.

[Cat]

SSd у меня стоит на sata-3, тут именно в проекте дело. Пока всего 231 VI если не считать dependencies по сравнению с AndreyDmitriev не много) Изначально есть 2 VI которые вызывают все остальные более мелкие, мне кажется все дело именно в интерфейсе. я сейчас использую tab control, а Вы AndreyDmitriev про Sub Panel говорите? Borjomy_1 если не сложно про "большой объем "забытых" данных из-за использования Probe с классами или массивами сложных кластеров" скажите, где поподробнее почитать?

[dadreamer]

я сейчас использую tab control

У меня вот тоже есть такие программы, где на всю ЛП Tab Control с кучей вкладок, в некоторых по ещё одному Tab Control'у, ну и собственно разные контролы/индикаторы, графики, картинки. Порой всё это дело заметно подтормаживает, не только при сохранении, но и при переключении ЛП-БД, при прокрутке мышью экрана, при переключении закладок Tab'а. Честно говоря, я просто забил на эти вещи, видимо, просто тяжело обрабатывать столько графических элементов одновременно.

[AndreyDmitriev]

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

[dadreamer]

AndreyDmitriev, наверное, в этом проблема отчасти. А ещё очень сильно влияет наличие IMAQ-дисплеев и картинок, назначенных по умолчанию. Замечал, что если полностью удалить эти дисплеи из программы, то всё начинает летать (в большинстве случаев).

[Cat]

В моем случае никаких данных на ЛП нет. Есть фоновые картинки, контроллы, правда все доработанные. Хм, я вот подумал, а может быть это из-за того, что картинки в контроллы я делаю в высоком разрешении? что бы при масштабировании хорошо выглядели, да еще и в png с альфами?

[dadreamer]

может быть это из-за того, что картинки в контроллы я делаю в высоком разрешении?

Сколько у вас картинок и какие у них размеры? Можно попробовать прикинуть, взвесив *.ctl файлы каждого контрола.

[Cat]

картинок около 100, исходное разрешение 200*100. не понял про взвешивание?

[dadreamer]

Ну, чем больше картинка, тем больше памяти она занимает при загрузке *.vi/*.ctl, так как она помещается непосредственно в ресурс. Для сравнения: *.ctl файл обычной кнопки без картинки весит 4 КБ. Если я размещаю на кнопке картинку, то такой файл весит как вся картинка (JPEG разжимается в PNG, например из 8,05 МБ становится 20,6). У вас на 1 картинку получается 200 * 100 * 24 = 480000 бит ≈ 58,59 КБ. На самом деле чуть меньше из-за сжатия. Если у вас 100 кнопок или других каких-то кастомных контролов на ЛП, то при загрузке будет израсходовано 58,59 * 100 = 5859 КБ ≈ 5,72 МБ памяти. Как показывают опыты, при помещении на ЛП нового контрола, пусть даже того же, что уже был на панели, создаёт новую копию картинки в памяти.

Хотя, почти 6 МБ для 100 контролов - это капля в море, по сравнению с тем, что обычно "ест" сам по себе. Проверить, влияют ли ваши картинки на тормоза , довольно просто: замените ваши контролы на стандартные и погоняйте программу.

[AndreyDmitriev]

может быть это из-за того, что картинки в контроллы я делаю в высоком разрешении?

Сколько у вас картинок и какие у них размеры? Можно попробовать прикинуть, взвесив *.ctl файлы каждого контрола.

Имеется ввиду - просто отсортируйте все файлы проекта по размеру и посмотрите на самые "увесистые". Скорее всего это будут как раз те файлы с навороченным UI.
Вот я сейчас посмотрел на тот проект, о котором писал выше - там общий объем vi и ctl примерно 200 МБ, что дает в среднем 40 кБ на файл. Самый большой - 1,3 МБ (и там реально дофига UI и кода). В остальном достаточно сложные инструменты не превышают 500-700 кБ. Если у вас сильно больше - то это повод пересмотреть концепцию интерфейса.
Картинки вообще нужно делать 1:1 - нет никакой особой необходимости делать их "с запасом". Те, которые меняют свои размеры должны быть векторные.
Мы,кстати, используем в подавляющем большинстве случаев инструменты из палитры System.
Несколько раз мы случайно оставляли IMAQ контролы с картинками (иногда просто отладочные) и запросто получали размер исходника мегабайт этак на 10-20 - тогда да, начинало тормозить.
Вы, кстати, DataBinding там нигде не используете? Скажем, если контролы подключены к OPC, а он не отвечает, то тоже может тормозить (впрочем в момент сохранения - маловероятно).
Еще как вариант - в свойствах инструмента попробуйте разделить компилят и исходник (надо отметить "separate compiled code from source code") - это немного уменьшит размер исходников и может сказаться на производительности.