Краткий ответ: Потому что во время работы легче идентифицировать и анализировать горячие точки - части вашей программы, которые используют больше всего времени.
Длинный ответ:
Если начать выполнение кода в режиме интерпретации виртуальная машина может рассчитывать, как часто и как долго используются различные части кода. Эти части могут быть оптимизированы лучше.
Взять вложенные предложения if-then-else. Меньшим логическим проверкам требуется меньшее время выполнения. Если вы оптимизируете путь для части, которая выполняется чаще, вы можете улучшить общее время выполнения.
Другое дело, что во время выполнения вы можете делать предположения, которые невозможно во время компиляции. Java-VM, например, встроена в виртуальные методы в режиме сервера - пока загружен только один класс, который реализует этот метод. Это было бы небезопасно, если бы это было сделано во время компиляции. JVM снова отключает код, если загружается другой класс, но часто этого никогда не происходит.
Также во время работы известно о машине, на которой работает программа. Если у вас есть машина с большим количеством регистров, вы можете использовать их. Опять же, это небезопасно, если сделать это во время компиляции.
Одно можно сказать: оптимизация во время выполнения также имеет недостатки. Самое главное: время для оптимизации добавляется к времени выполнения программы. Также это сложнее, потому что вам приходится компилировать части программы и выполнять их. Ошибки на виртуальной машине имеют решающее значение. Подумайте о компиляторе, который иногда сбой - вы можете снова скомпилировать, и все в порядке. Иногда сбой виртуальной машины иногда означает, что иногда ваша программа рушится. Нехорошо.
В заключение: Вы можете выполнять каждую оптимизацию во время выполнения, что возможно во время компиляции ... и еще несколько. У вас есть дополнительная информация о программе, это пути выполнения и машина, на которой работает программа. Но вы должны учитывать время, необходимое для выполнения оптимизации. Кроме того, это сложнее делать во время выполнения, а ошибки более актуальны, чем во время компиляции.
Я думаю, что Стив Йегги имел в виду «легче получить лучшие результаты», а не «легче сделать», так я думаю, что вы его интерпретируете. В конце концов, я полагаю, что перестановка программы сложнее, чем во время компиляции. – Pod