Почему люди разбирают двоичные файлы .NET (CLR)? - PullRequest
Новая
       39

Почему люди разбирают двоичные файлы .NET (CLR)?

4 голосов
/ 30 мая 2009

Я немного новичок в .NET, но не новичок в программировании, и я несколько озадачен тенденцией и волнением по поводу разборки скомпилированного кода .NET. Это кажется бессмысленным.

Именно из-за простоты использования .NET я использую его. Я написал C и реальную (аппаратный процессор) сборку в средах с ограниченными ресурсами. Это и стало причиной того, что мы потратили много усилий на детали, для повышения эффективности. Находясь в среде .NET, он как бы побеждает цель иметь высокоуровневый объектно-ориентированный язык, если вы тратите время на погружение в самые загадочные детали реализации. В ходе работы с .NET я отлаживал обычные проблемы с производительностью в странных условиях гонки, и я сделал все это, читая свой собственный исходный код, никогда не задумываясь о том, какой промежуточный язык генерирует компилятор. Например, довольно очевидно, что цикл for (;;) будет быстрее, чем foreach () в массиве, учитывая, что foreach () будет использовать перечисление object с вызовом метода переходить к каждому следующему разу вместо простого приращения переменной, и это легко доказать, если несколько миллионов раз выполнить тугой цикл (разборка не требуется).

Что действительно делает разборку IL глупой, так это то, что это не настоящий машинный код. Это код виртуальной машины. Я слышал, что некоторым людям нравится перемещать инструкции, чтобы оптимизировать их. Ты шутишь, что ли? Скомпилированный точно в срок код виртуальной машины не может даже выполнить простой цикл for (;;) со скоростью скомпилированного кода. Если вы хотите выжать каждый последний цикл из вашего процессора, то используйте C / C ++ и потратьте время на изучение реальной сборки. Таким образом, время, потраченное на понимание множества деталей низкого уровня, будет действительно полезным.

Итак, кроме того, что у них слишком много времени, почему люди разбирают двоичные файлы .NET (CLR)?

Ответы [ 13 ]

0 голосов
/ 31 мая 2009

Я использовал его в следующих случаях:

  1. Возникла проблема с внутренней сборкой, для которой у меня не было исходного кода.
  2. Требуется выяснить, как конкретная сторонняя библиотека элементов управления ищет лицензию времени выполнения.
  3. Необходимо выяснить, как работает лицензионный компилятор .Net. (Только что поместил lc.exe внутри рефлектора)
  4. Используется для проверки правильности сборки определенных библиотек.
0 голосов
/ 31 мая 2009

Чтобы понять, как реализована базовая система, понять, что эквивалентно высокоуровневому коду в IL, обойти лицензирование ...

0 голосов
/ 30 мая 2009

Мне самому часто это интересно ...:)

Иногда необходимо понять, как работает конкретный библиотечный метод или почему именно он работает таким образом. Может быть ситуация, когда документация по этой функции расплывчата или есть какое-то странное поведение, которое требует изучения. В этом случае некоторые люди идут разбирать библиотеки, чтобы посмотреть, какие вызовы внутри определенных методов сделаны.

Что касается оптимизации, я никогда не слышал об этом. Я думаю, что в конечном итоге глупо пытаться оптимизировать MIL, поскольку затем он будет передан транслятору, который будет генерировать настоящий машинный код с довольно хорошей эффективностью, и ваши «оптимизации» могут в любом случае потеряться.

Страница:
...