Время – наш самый ценный ресурс. В этой статье вы найдёте 11 способов существенно ускорить работу Revit и сильно сэкономить своё время.
Комплектующие ПК
Скорость работы комплектующих ПК> Время
Одним из главных факторов, влияющих на скорость работы Revit, являются комплектующие вашего компьютера. При оценке времени той или иной операции совершаемой программой вы должны учитывать возможности определённых комплектующих.
- Повышенная частота процессора позволит ускорить процессы перерисовки видов и регенерации спецификаций. Рекомендуется: не менее 3 ГГц
- Высокоскоростной жёсткий диск позволит повысить скорость открытия и сохранения модели. Рекомендуется: SSD М2
- Большой объём оперативной памяти и её высокая частота позволяют работать с моделями больше 500 Мб. Рекомендуется: не менее 32Гб 3200MHz
- Видеокарта не играет главную роль в производительности и влияет только на скорость вращения 3d вида и корректность прорисовки текстур. Рекомендуется: вычислительная производительность FP16 не менее 6,0 терафлопс.
Более подробно узнать о комплектующих для стационарного компьютера и ноутбука вы можете узнать в статье «Как подобрать ПК для Revit?»
✅ Как ускорить компьютер/ Ускоритель компьютера/ Оптимизация компьютера/ Настройка компьютера
Расположение файлов на компьютере
Место расположения файлов проекта> Скорость открытия и сохранения> Время
Довольно часто встречается ситуация, когда для хранения данных на компьютере используются два жёстких диска – SSD и HDD.
Твердотельный жёсткий диск SSD в четыре раза быстрее HDD диска, но и намного дороже. Поэтому SSD обладает меньшей ёмкостью и в первую очередь используется для операционной системы, а HDD с большой ёмкостью для хранения медиаконтента и текстовых файлов.
При работе с Revit важно хранить локальные файлы пользователя на быстром SSD. Желательно использовать SSD диски с разъёмом для подсоединения М2. Это позволит в несколько раз быстрее открывать и сохранять файлы модели.
Решение: для перенастройки пути сохранения файлов в Revit нажмите Файл> Параметры> Файлы> Путь по умолчанию для пользовательских файлов и выберете папку, располагающуюся на SSD диске, в большинстве случаев это диск «С».
Однако, будьте осторожны диски с небольшим объёмом – 128Gb крайне не рекомендуется использовать как место хранения пользовательских файлов. Во время работы с моделью Revit создаёт большое количество временных файлов, которые быстро заполнят диск небольшой ёмкости и создадут проблемы с сохранением файла проекта.
Отключение Рабочих наборов
Количество открытых рабочих наборов> Время
Всегда помните, что, создавая рабочие наборы и группируя их по каким-либо проектным признакам, вы ускоряете не только свою работу, но и работу ваших коллег!
Открытие файла проекта с большим количеством связанных моделей, может превратиться в довольно долгий процесс. Это связано с тем, что при открытии основного файла Revit каждый раз обновляет все связанные файлы.
Как ускорить работу windows 10 ? Максимальная производительность !
Хорошим примером модели с огромным количеством объектов и связанных моделей является модель инженерных систем на уровне паркинга, когда для работы инженеру требуется архитектура, конструктив и все сопутствующие инженерные системы здания.
Решение: рекомендуется
- каждому из связанных файлов назначать отдельный рабочий набор, пример: _01_Связь_АР
- отключить ненужные для проектировщика рабочие наборы в связанных моделях. Примером рабочих наборов, которые не нужны Инженерам раздела ИОС являются ТЭПы, Генплан, Арматура, Связи.
- уменьшить уровень детализации объектов в связанных моделях.
При открытии проекта с совместным доступом имеется возможность выбора рабочих наборов, которые требуется закрыть. Закрытые рабочие наборы не отображаются в проекте, поэтому производительность работы повышается. Оставьте открытыми только те рабочие наборы, которые необходимы Вам для дальнейшей работы.
Для ОТКЛЮЧЕНИЯ рабочих наборов в связанных моделях:
Вставить > Диспетчер связей > Выбираем связанную модель > Управление рабочими наборами
Выбираем рабочие наборы, которые необходимо закрыть > Нажимаем кнопку «Закрыть» > В столбце «Открыт» изменится статус с «Да» на «Нет»
Уменьшение уровня детализации в связанной модели
На виде Свойства > Переопределение видимости > Связанные файлы > По основному виду > Пользовательские > Уровень детализации > Низкий
Надстройки для Revit – плагины
Количество монотонных процессов> Время
Используя функционал Revit из раза в раз, мы сталкиваемся с большим количеством однообразных и монотонных процессов, которые отнимают большое количество времени. Для возможности автоматизировать такие процессы Autodesk предоставляет возможности по созданию программ – плагинов.
Решение: устанавливаем плагин Future BIM.
Ускорение программы: изменение приоритета процесса
Доброго времени друзья Вы знаете, что есть небольшой трюк, который позволяет ускорить почти любую программу или даже игру.. не знаете? А зря, потому что думаю вам это будет интересно
Итак, сперва немного не о том. Что самое главное в компьютере и от чего зависит производительность? Если вы ответите что оперативная память — то будете правы, но не полностью, а почти. Самый главный в компе это его величество процессор, но он один, ну может ядер много, но самих процессов в Windows куда больше.
Как так сделать, чтобы всем хватало процессора? Правильно, он просто по очереди обрабатывает команды, там их ну очень много, тысячи в секунду наверно, я честно таких подробностей не знаю
Но суть в том, что в Windows есть такая система как приоритеты, то есть кому-то в первую очередь нужно отдать мощь процессора, а кто-то может обойтись и получить ее последним в списке.
О чем это я? Это я о приоритетах, которые применяются к программам. А что такое программа? Это процесс. Эти приоритеты в Windows есть давно, наверно даже есть в более старых версиях чем Windows XP (какая же все таки хорошая была система, пока не устарела).
Каждому процессу Windows дает приоритет, если его нет, то он по умолчанию средний. Есть критически важные процессы, им Windows задает высокие приоритет или даже реального времени, да-да, все так серьезно
Но мы тоже можем задать приоритет! Например.. вы играете в какую-то игру, или запустили какую-то программу, в общем это все неважно, смотрите, пусть у нас Мозилла это будет очень важная игра, ну представим просто Теперь вот небольшая инструкция как ее ускорить до максимума.
1. Сперва открываем диспетчер задач, правой кнопкой по панели задач и там выбираем пунктик нужный:
2. Тут есть два варианта — или сразу перейти к процессам, или узнать процесс через программу, я покажу второй вариант. Нажимаем правой кнопкой по той программе, которую нужно ускорить и нажимаем Подробно, чтобы сразу перейти к процессу (а можно его и вручную поискать на вкладке Подробности):
3. По выделенному процессу, а это у нас firefox.exe, нажимаем правой кнопкой и устанавливаем Высокий приоритет:
4. Все, теперь программа Мозилла будет работать намного быстрее, как и любая программа, которой вы задали таким способом приоритет.
Но можно конечно и задать Реального времени.. Но это очень высокий приоритет, настолько высокие, что самой системе может вообще не остаться ресурсов, и могут быть критические глюки Поэтому я его и не советую выставлять.
Таким образом можно игру ускорить, ну или еще что-то, например какой-то фото-редактор.
Но запомните, что при повторном запуске программы, приоритет ей будет автоматически задан по умолчанию Обычный, то есть если нужно снова ускорить — придется вручную это делать. Но это мне кажется не так уж и сложно
Ну все, ребята, чао-какао
Источник: virtmachine.ru
Home
Работа с тестовыми инструментами обычно начинается с немедленной яростной обратной связи. Со временем программисты добавляют новые фичи, тестировщики – новые тесты, и тесты занимают все больше и больше времени. Чтобы чем-то себя занять, технический персонал работает над чем-нибудь еще, ожидая, пока тесты закончат работу.
Рано или поздно тест-результаты становятся такими медленными, что уже неактуальны – а даже если актуальны, нуждаются в археологах, чтобы разобраться, что в них вообще происходит. Все это можно предотвратить быстрой обратной связью.
Мои советы нацелены на ускорение петли обратной связи: тестируйте меньше, распределяя тесты во времени и пространстве. Для этого придется запускать расширенный набор инструментов, коммерческих или открытых, предоставляющих большее покрытие при более медленном темпе и быстрейшими, наиболее важными тестами, работающими непрерывно.
1. Выкиньте лишние операции из GUI-тестов
Предположим, ваш тест проверяет, могут ли пользователи видеть друг друга с двух разны учеток. Тест требует двух учеток, двух пользователей, и каких-нибудь выдуманных данных. Каждый шаг подготовки к тесту может занимать 30 секунд через пользовательский интерфейс, но выполняться за полсекунды через командную строку.
Эти операции понадобятся и где-нибудь еще; они тут совершенно лишние. Добавьте установочные функции, чтобы быстро подготовиться к тесту, или заведите образцовую базу данных для тестов (мы еще поговорим об этом).
Наше следующее решение – сдвинуть эти тесты на уровень API.
2. Сдвиньте бизнес-логику к интеграционным тестам API
По сравнению с фронт-эндом веба, микросервисы и другие API достаточно прочны, вряд либудут меняться, и еще они очень быстрые. В отличие от других юнит-тестов, которые редко влияют на пользователя, API-тесты обычно могут быть выражены так, что их поймет пользователь, и могут быть привязаны к действиям пользователя. К примеру: ожидаем такого-то результата с учетом пользователя с этим типом данных и особого ввода данных.
С поиском это вообще проще некуда – заведите базу данных с известными заранее подготовленными данными, запустите поиск, ожидайте результатов. Храните запрос и ожидаемые результаты там, куда есть доступ у людей бизнеса и технарей – возможно, на том же уровне, что и GUI-тесты – и у вас будет исполняемая спецификация.
Эти тесты будут запускаться без старта браузера, ввода логина и пароля, клика на подтверждении, заполнении страницы поиска, и запуска любого JavaScript.
Для этого нам нужны хорошие данные в качестве результатов поиска, что приводит нас к следующему фокусу.
3. Создайте базу данных с образцами
Как-то раз я работал на одну страховую фирму. Она периодически обновляла тест-сервер, пополняя его данными с прода. Для теста нам нужно было или искать в базе пользователей, удовлетворявших нужным условиям, или настраивать их самостоятельно. Первый процесс был по большей части ручным, делая применение инструментария невозможным, а второй занимал время. Даже если бы мы могли выйти за пределы GUI, то создание тестовых пользователей, групп, подгрупп, запросов на заказ и ответов на запрос заняло бы много времени на кодирование, и добавило бы время к каждому прогону тестов.
Вместо этого я предпочел полезные функции, позволяющие экспортировать и импортировать базу данных. Если у вашего ПО есть такие сущности, как «учетная запись» или «группа», то вам может пригодиться экспорт части базы данных – возможно, всех пользователей этой учетки или группы. В дополнение к тестируемости, это также позволяет быстрое сохранение и восстановление, тестируемое автоматически, каждый спринт, самим тест-процессом.
Если тесты создают информацию – пользователей или заказы – возможно, можно экспортировать конечный результат и сравнить его с другой базой данных известных результатов при помощи функции «diff». Дифференцирование целой базы данных после прогона тестов может найти скрытые дефекты, которые тестировщики и не думали искать.
Импорт и экспорт заведомо «хороших» данных также позволяет ускорить настройку системы.
4. Ускорьте или избавьтесь от настройки и демонтажа.
Серьезная настройка и демонтаж между тестами – очень популярная идея. При условии небольших тестов и отсутствии «кровотечений» между ними ожидаемый результат легко определить, и дебаг проходит без проблем.
Множество небольших тестов также означает, что фреймворк будет множество раз запускать настройку. В большинстве компаний, где я работал, разрабатывалось множество тестов на века. Это означало, что двухминутные настройка и демонтаж добавляли целые часы к прогону тестов.
Самый простой способ ускорить настройку – это вообще ее не проводить, помечая ряд тестов как «только для чтения». Тест-фреймворк может прогнать любой тест, следующий за таким отмеченным тестом, без демонтажа или настройки.
Другой способ пропустить настройку – это создание пользовательских сегментированных учетных записей. К примеру, если тесту нужна запись данных, начните с создания учетной записи по имени «название_теста%%дата_время%%». Временная отметка даст вам уникальность учетки, и пока учетки не могут видеть данные друг друга, следующему тесту не потребуется демонтаж и настройка.
Даже в случае информационного дренажа в некоторых случаях можно поднять новые тестовые данные вверх – сортируя по дате создания, например. В некоторых случаях загрузка тестовой базы данных быстрее, нежели полная настройка. В других тесту не нужна база данных, а нужен только один пользователь.
Ключ к успеху тут кроется в выяснении минимального количества зависимых операций, требующихся, чтобы тест прошел. Как только это сделано, посмотрите на вебсервер и базу данных, как на проект по тестированию производительности. Найдите узкие места, посчитайте задержку, которую эти места вызывают, и подумайте, не нужны ли тут перемены.
5. Оптимизируйте результаты клиентского браузера
Посмотрите на то, где прогоняются тесты и как быстро это происходит. Бесперебойная работа старых браузеров ведет к утечкам памяти; фермы виртуальных машин довольно медленны. Посмотрите на задержку распространения от тестового веб-сервера к тестовому клиенту, взгляните, насколько быстро работает ПО, обслуживающее эти клиенты. Это также применимо к нативному мобильному софту и железу.
Рассматривая самую первую, наиболее глубокую петлю тест-процесса, подумайте о запуске браузера без интерфейса. Браузер без интерфейса полностью контролируется программой и не создает пользовательский интерфейс.
Альтернатива запуску браузера без интерфейса – создание видео прогона теста. Это не ускорит выполнение теста, но уж точно ускорит дебаг! Видео-стратегия обычно приносит ценность на другом конце петли обратной связи – при ночных прогонах.
6. Устраняйте неприятные периоды ожидания
Ожидание появления элементов – классическая проблема тестирования пользовательских интерфейсов. Ленивый подход – заложить в код жесткое ожидание, что-то между 15 и 30 секундами. Когда эти тесты упадут (а они упадут), тестировщик просто удваивает время ожидания.
При 30 секундах ожидания и нескольких сотнях тестов общее время прогона тестов увеличивается на часы. Если уменьшить этот период, ждать надо будет меньше, однако возникнет риск, что проверка будет проходить, когда рендер страницы еще не завершен.
У большинства современных инструментов есть методы wait_for_element_present_ok method, или wait_for_page_load, или способность построить подобные методы внутри существующего тест-фреймворка. Боритесь за эту способность или терпите гигантское время прогона и ложноотрицательные результаты.
Куртис Петит, ведущий тестировщик и консультант, напомнил мне, что wait_for_element_present_ok и схожие методы могут быть закодированы как-нибудь так:
while (timeNotExpired) If (condition) return true;
else recalcTime;
> return false;
Построить такую функцию на чем-нибудь вроде JavaScript довольно легко. Единственный вопрос, поддерживает ли фреймворк поиск по условию.
7. Получайте преимущество от тегов
Когда я работал в Socialtext, системные GUI-тесты были выражены в форме wiki-страничек. Каждая страница могла быть помечена: к примеру, у нас были «тесты солнечного света», «тесты базы данных», «поисковые тесты» и «профильные тесты».
Тесты также размечались по браузерам, так как IE и Safari не поддерживали все функции наших инструментов. Тесты солнечного света прогонялись примерно полчаса и давали базовое покрытие всего приложения. Профильные и поисковые тесты также прогонялись быстро и давали глубокое покрытие специфической области. Тэги можно комбинировать – к примеру, запустить все поисковые тесты для IE, или все профильные тесты для Firefox.
Описание тестов при помощи тэгов (меток) позволяет программистам писать разумные запросы на то, какие тесты запустить, и это дает нам наиболее приемлемое покрытие за минимум времени.
8. Запускайте тесты параллельно на нескольких клиентах
И, напоследок, мы дошли до параллельности тестов.
Теоретически, если работа инструмента тестирования разрезана на 100 небольших тестов, запуск которых занимает от пяти до десяти минут, с двумя минутами на настройку – их можно поделить на сто виртуальных машин и запустить их все минут за тринадцать. Существуют инструменты, упрощающие эту работу так, что это делается одной командой.
Запуск параллельных тестов означает использование публичного или частного облака. Частное облако позволит запуск 10-20 одновременных тестов. Запуск 100 одновременных тестов на одном веб-сервере, скорее всего, приведет к временным проблемам и проблемам дебага. Тесты, не предназначенные для одновременного запуска, будут портить данные друг друга, и это приведет или к плохо написанным тестам, или – что более вероятно – большому труду по их переписыванию и пересмотру, чтобы они могли работать параллельно.
Если компания может пользоваться публичным облаком, а продукт хорошо подходит для параллельного запуска тестов – неважно, открытый у него исходный код или коммерческий – то запуск множества тестов одновременно может серьезно улучшить системную производительность. Главное, не давайте этому факту стать аргументом для разгильдяйской, медленной работы инженеров
Полная картина
Основная стратегия, которую я предлагаю – тестировать меньше, избавляться от лишних тестов, ускорять элементы тест-прогона. Запускайте минимальное количество возможных тестов для быстрой обратной связи – до и после коммита – затем более крупный набор несколько раз в день, и полный набор ночью.
Стремитесь, чтобы индивидуальный компонент – такой, как API – мог быть развернут индивидуально и дефекты были привязаны к переменам кода, и чтобы вы могли избавиться от необходимости полной, затрагивающей пользователя автоматизации насовсем.
Не думайте об этом как о цели. Думайте об этом, как о направлении, делая шаг за шагом.
Источник: www.software-testing.ru