Вы когда-либо использовали ngen.exe?
Попробуйте использовать doc.data
listCour.add(doc.data);
Firestore.instance
.collection('MATH')
.document(doc.documentID)
.collection("cours")
.getDocuments()
.then((QuerySnapshot snapshot) {
snapshot.documents...
})
5 ответов
Да, я видел повышения производительности. Мои измерения указали, что это действительно улучшало производительность запуска, если я также поместил свои блоки в GAC, так как мои блоки все сильны названный. Если Ваши блоки будут сильны названный, то NGen не будет иметь никакого значения, не используя GAC. Причина этого состоит в том, что, если у Вас есть сборки со строгим именем, которые не находятся в GAC, затем время выполнения.NET проверяет ту Вашу сборку со строгим именем, не вмешался путем загрузки целой управляемой сборки из диска, таким образом, это может проверить его обходящий одно из главных преимуществ NGen.
Это не было очень хорошим вариантом для моего приложения, так как мы полагаемся на общие блоки от нашей компании (которые являются также сильны названный). Общие блоки используются многими продуктами, которые используют много различных версий, помещение их в GAC означало, что, если бы в одном из наших приложений не было сказано "использование определенная версия" одного из общих блоков, это загрузило бы версию GAC независимо от того, какая версия была в своем каталоге выполнения. Мы решили, что преимущества NGen не стоили рисков.
Я не использую его ежедневный, но это используется инструментами, которые хотят повысить производительность; например, Paint.NET использует NGEN во время установщика (или возможно первое использование). Это возможно (хотя я не знаю наверняка), который некоторые инструменты MS делают, также.
В основном NGEN выполняет большую часть JIT для блока впереди, так, чтобы было очень мало задержки на "холодном" запуске. Конечно, в самом типичном использовании, не 100% кода когда-либо достигаются, таким образом, до некоторой степени это делает большую ненужную работу - но это не может сказать это заранее.
Оборотная сторона, IMO, то, что необходимо использовать GAC для использования NGEN; я стараюсь избегать GAC как можно больше, так, чтобы я мог использовать robocopy-развертывание (для серверов) и ClickOnce (клиентам).
Ngen главным образом уменьшает время запуска приложения.NET и рабочего набора приложения. Но это, имеют некоторые недостатки (от CLR Через C# Jeffrey Richter):
Никакая защита интеллектуальной собственности
Файлы NGen'd могут выйти из синхронизации
Нижняя производительность времени загрузки (перебазирование/Привязка)
Нижняя производительность времени выполнения
Из-за всех проблем, просто перечисленных, необходимо быть очень осторожными при рассмотрении использования NGen.exe. Для приложений серверной стороны NGen.exe имеет минимальный смысл, потому что только первый клиентский запрос испытывает хит производительности; будущий клиент запрашивает выполненный в высокой скорости. Кроме того, для большинства серверных приложений, только один экземпляр кода требуется, таким образом, нет никакого преимущества рабочего набора.
Для клиентских приложений NGen.exe мог бы иметь смысл улучшать время запуска или уменьшать рабочий набор, если блок используется несколькими приложениями одновременно. Даже в случае, в котором блок не используется несколькими приложениями, NGen'ing, блок мог улучшить рабочий набор. Кроме того, если NGen.exe будет использоваться для всех блоков клиентского приложения, то CLR не должен будет загружать JIT-компилятор вообще, уменьшая рабочий набор еще больше. Конечно, если всего один блок не будет NGen'd или если файл блока NGen'd не может использоваться, JIT-компилятор загрузится, и увеличения рабочего набора приложения.
ngen главным образом известен улучшением времени запуска (путем устранения JIT-компиляции). Это могло бы улучшиться (путем сокращения времени JIT) или уменьшить общую производительность приложения (так как некоторая оптимизация JIT не будет доступна).
Сама Платформа.NET использует ngen для многих блоков на установку.
я использовал его, но только для цели исследования. используйте его, ТОЛЬКО ЕСЛИ Вы уверены в архитектуре ЦП своей среды развертывания (это изменение привычки)
но позвольте мне сказать Вам, что JIT-компиляция не слишком плоха и если у Вас есть развертывание через несколько сред CPU (например, клиентское приложение окон, которое часто обновляется), ЗАТЕМ НЕ ИСПОЛЬЗУЮТ NGEN. поэтому, допустимый ngen кэш зависит от многих атрибутов. если один из них перестал работать, Ваш блок отступает к монете в пять центов снова
JIT является явным победителем в таких случаях, поскольку он оптимизирует код на лету на основе архитектуры ЦП его работа. (для, например, это может обнаружить, если существует более затем 1 CPU),
и сброс является улучшением с каждым выпуском, таким образом, в короткой палке с JIT, если Вы не абсолютно уверенны из своей среды развертывания - даже затем Ваше увеличение производительности едва выровняло бы по ширине использование ngen.exe (вероятно, усиления будут в небольшом количестве сотни мс) - по моему скромному мнению - не стоящий усилий
также проверьте эту реальную хорошую ссылку на эту тему - JIT-компиляцию и Производительность - К NGen или Не к NGen?