Несколько лет назад я работал в лаборатории сборки в Microsoft, которая обрабатывала много управляемого кода. Позвольте мне укрепить это, это было много лет назад, прежде чем управляемый MPGO был публичным. Но тогда они будут использовать старые данные профиля (обычно с предыдущего дня, но иногда до недели), чтобы «частично оптимизировать» набор внутренних двоичных файлов. Я не могу говорить с цифрами, но мы бы этого не сделали, если бы у него не было никакой пользы. Эти «частично оптимизированные» двоичные файлы будут использоваться только для автоматизированного тестирования дыма и предназначены только для внутреннего использования. Только полностью оптимизированные бинарные файлы (данные профиля которых были собраны из одной сборки) будут выпущены.
Я не эксперт, но из того, что я понимаю, данные руководства MPGO используют сигнатуры методов (например, используемые символами отладки) и смещения файлов, которые не являются стабильными между сборками. Тогда возникает вопрос: какой процент достаточно стабилен, чтобы иметь какую-то выгоду?
Скажем, имя метода изменяется для метода, который используется много. Тогда, конечно, «горячие» страницы в старой двоичной системе (из-за этого метода) не будут найдены в новом двоичном файле, а страница, которая будет использоваться много, вероятно, будет помещена в конец «оптимизированного двоичного файла» с кодом, который никогда не используется. На другой стороне монеты: какой% методов переименовывается из одной ежедневной сборки? (Или еще чаще с CI?) Я бы предположил, что менее 1%.
Позвольте мне вернуться к внутренним сборкам. Разумеется, сбор новых данных перфоманса занял некоторое время, поэтому внутренние функции, зависящие от времени (которые должны запускаться сразу после сборки), будут выполняться с использованием частично оптимизированного вкуса сборки, поскольку эта сборка завершится за несколько часов до полностью оптимизированного вкуса сборки , Позвольте мне объяснить, почему так долго. IIRC мы использовали профильные «проходы», где сначала запускаются сценарии основной библиотеки, эти двоичные файлы оптимизированы, а оптимизированное ядро используется в более поздних сценариях «сквозной» (т.е. серверный веб-сервис или клиентский интерфейс GUI сценарии). Таким образом, основные библиотеки могут быть профилированы и оптимизированы несколько раз. Как вы можете догадаться, все это требует времени, поэтому «полностью проанализированная/оптимизированная» сборка заняла время LONG.
Я надеюсь, что это было полезно.
P.S. Этот вопрос напомнил мне 32-bit DLL rebase issues.