Почему aspnet_compiler.exe такой медленный (и его можно сделать быстрее)?
https://stackoverflow.com/questions/289831
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Во время процесса сборки мы запускаем aspnet_compiler.exe на наших веб-сайтах, чтобы убедиться, что все компоненты с поздним связыванием в ASP.NET/MVC действительно собираются (я ничего не знаю о ASP.NET, но уверен, что это необходимо для предотвращения обнаружения сбоев во время выполнения).
Наши сайты довольно большие по размеру, с несколькими сотнями страниц / просмотров / элементов управления / и т.д. однако время, которое кажется слишком большим в диапазоне 10–15 минут (для справки, это больше, чем требуется для компиляции всего решения с примерно 40 проектами, а мы только предварительно компилируем два проекта веб-сайта).
Я сомневаюсь, что проблема заключается в аппаратном обеспечении, так как я работаю на последнем четырехъядерном чипе Intel с 4 ГБ ОЗУ и жестким диском WD Velociraptor 10 000 об / мин. И отчасти то, что странно, это то, что EXE, кажется, не использует много ресурсов ЦП (1-5%) и, по-видимому, не выполняет слишком много операций ввода-вывода.
Итак ... это известная проблема? Почему это так медленно? И есть ли способ ускорить его?
Примечание. Чтобы прояснить пару вопросов, о которых люди ответили, я не говорю о компиляции кода в Visual Studio. Мы уже используем проекты веб-приложений, и скорость их компиляции не является проблемой. Проблема заключается в предварительной компиляции сайта после того, как эти проекты уже были скомпилированы ( см. эту страницу MSDN для получения дополнительной информации ) как часть сценария сборки dev. Мы выполняем предварительную компиляцию на месте, а не копируем файлы в целевой каталог.
Решение
Другие советы
Переход на компилятор Roslyn, скорее всего, значительно улучшит время предварительной компиляции. Вот хорошая статья об этом: http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp -сетью-applications.aspx .
В дополнение к этому, убедитесь, что пакетная компиляция включена, установив для атрибута batch значение true в элементе компиляции.
Просто aspnet_compiler использует то, что фактически является "глобальной блокировкой компилятора". всякий раз, когда начинается предварительная компиляция любой отдельной страницы ASPX; в основном разрешено только последовательно компилировать каждую страницу.
Для этого есть причины (хотя я лично с ними не согласен) - прежде всего, для обнаружения и предотвращения циклических ссылок, вызывающих бесконечный цикл сортировок, а также для обеспечения правильного построения всех зависимостей до компиляции требуемой страницы. они избегают многих «неприятных проблем с CS».
Однажды я начал писать разветвленную версию aspnet_compiler.exe в прошлый раз, когда работал в веб-компании, но был связан с «реальной работой». и никогда не заканчивал это. Самая большая проблема - это страницы ASPX: материал MVC / Razor, из которого можно распараллелить АД, но механизм синтаксического анализа / компиляции ASPX имеет глубину около 20 уровней внутренних и частных классов / методов.
У меня нет специальных советов для этого компилятора, но когда у меня возникают проблемы такого рода, я запускаю ProcMon, чтобы посмотреть, что происходит на компьютере, и запускаю Wireshark, чтобы убедиться, что это не так. затрачивая время на отключение доступа к сети к давно забытому компьютеру, на который ссылается какой-то ключ реестра или переменная среды.
Просто мои 2 цента.
Одной из вещей, значительно замедляющих прекомпиляцию представлений ASP.NET, является параметр командной строки -fixednames для aspnet_compiler.exe . Не используйте его , особенно если вы используете Razor / MVC.
При публикации приложения wep из Visual Studio убедитесь, что вы выбрали "Не объединять", а Не выберите "Создать отдельную сборку". потому что это то, что вызывает глобальную блокировку и замедляет работу.
Дополнительная информация здесь https: // msdn .microsoft.com / EN-US / библиотека / hh475319 (v = vs.110) .aspx
