GAC по сравнению с JIT
Проблема заключается в удалении пробелов. Так что попробуйте jsonStr.replaceAll("\\s+","")
4 ответа
Нет, GAC не автоматически pre-JITted; однако, GAC является предпосылкой к предварительному JIT. На самом деле, только малочисленное меньшинство вещей pre-JITted. Помимо которого - если бы BCL был pre-JITted, то те оптимизации были бы уже сделаны NGEN, таким образом, "потеря всей потенциальной оптимизации" является надуманным вопросом.
Нет, глобальный кэш сборок не предварительно компилируется.
Более новые версии платформы действительно имеют сервис оптимизации, работающий в фоновом режиме, который делает некоторую предварительную компиляцию. Но поскольку это работает на целевой системе вся предварительная компиляция, которую это делает оптимизирован для той определенной системы.
Если блок загружается из GAC, проверка строгого имени пропускается, потому что блок был уже проверен. Другим преимуществом GAC является защита файла (только для администратора).
NGEN имеет свое собственное устройство хранения данных для собственных изображений. Имеет немного смысла использовать NGEN, не помещая блок в GAC сначала. В таком случае, загружающем блок, вызвал бы для проверки его подписи SN, что означает, что криптографический хеш воссоздается каждый раз, когда блок загружается.
Лучшая практика при использовании ngen должна поместить блоки в GAC также.
GAC может содержать код non-ngen'd (он должен содержать его, а также собственные изображения при использовании ngen, так как ngened изображения не содержат все необходимые метаданные). Код Ngen'd требует, чтобы dll были установлены в GAC для функционирования эффективно (технически, можно сделать это без, но получающаяся проверка имени инициировала полное чтение dll так или иначе, который, вероятно, сделает время запуска хуже).
Пред 3,5 sp1 ngen компиляция определенно незначительно отличалась от во время выполнения, см. эту статью еще для некоторых деталей. Я предположил бы, что это все еще сохраняется для 3.5SP1, так как те проблемы трудно решить.
С тех пор ngen только действительно дает Вам две больших победы, которые необходимо рассмотреть, является ли любой/и значительным в сценарии, чтобы выровнять по ширине сложность и стоить связанный с их использованием.
- Время запуска для тех dll's очень уменьшается
- Быть действительно большой победой, хотя весь dlls, загруженный при запуске, должен быть ngened для предотвращения издержек загрузки самой монеты в пять центов),
- Собственные изображения могут совместно использовать пространство памяти через несколько процессов.
- Довольно бессмысленный, если Вы только выполняете один или два процесса.
Я предполагаю, что Эта статья, детализирующая некоторые изменения в 2.0 ngen, является хорошим чтением, она покрывает вещи как трудная привязка, которая является большим улучшением и связывается в с превосходной общей документацией при написании эффективного управляемого кода, хотя она пострадала от гнили ссылки, видят Главу 5 MSDN, к которой она относится. (обратите внимание, что тот документ стар, но многие темы все еще допустимы),