Я в целях упрощения и ускорения сборки проекта на N написал небольшую make-подобную утилиту, которая использует API компилятора — не выгружая его сборки, производит последовательную компиляцию нескольких сборок проекта. На маленьких скорость достигает 3 в секунду. Скорее всего, если дать компилятору не выгружать библиотеки между билдами, скорость можно поднять ещё. Но в соответствующем режиме (PersistentLibraries = true) между этими самыми билдами нельзя менять ReferencedLibraries — то есть менять-то можно, но это ничего не дает.
Нельзя ли сделать так, чтобы в этом режиме подгружались ранее не использованные (только что собранные) dll-ки?
В принципе, если интересно, утилитой могу поделиться — она прекрасно прикручивается к SciTE.
P.S. Что-то в последнее время в decl стало много тем про N, не пора ли всё-таки выделить соответствующий форум...
30.01.07 17:51: Перенесено модератором из 'Декларативное программирование' — IT
Здравствуйте, Алексей П, Вы писали:
АП>Я в целях упрощения и ускорения сборки проекта на N написал небольшую make-подобную утилиту, которая использует API компилятора — не выгружая его сборки, производит последовательную компиляцию нескольких сборок проекта.
Хм. 3 секунды — это очень много. После pre-JIT-а компиляторых сборок у меня где-то до 3 секунд (а то и быстрее) собирается проект Интеграции со судией.
Проблема только в том, что такой подход будет блокировать сборки. Ведь компилятор вынужден подлючать их чтобы считать информацию о типах.
АП> Скорее всего, если дать компилятору не выгружать библиотеки между билдами, скорость можно поднять ещё. Но в соответствующем режиме (PersistentLibraries = true) между этими самыми билдами нельзя менять ReferencedLibraries — то есть менять-то можно, но это ничего не дает.
Да, вроде бы это есть. Мы используем кэширование в Интеграции. Незнаю насклько только это прокатит на несколько проектов.
АП>Нельзя ли сделать так, чтобы в этом режиме подгружались ранее не использованные (только что собранные) dll-ки?
Не понял.
АП>P.S. Что-то в последнее время в decl стало много тем про N, не пора ли всё-таки выделить соответствующий форум...
Посмотрим. Если интерес будет постоянным, или будет возрастать, то перенесем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > АП> На маленьких скорость достигает 3 в секунду. > > Хм. 3 секунды — это очень много. После pre-JIT-а компиляторых сборок у > меня где-то до 3 секунд (а то и быстрее) собирается проект Интеграции со > судией.
3 шт/с — это не 3 с/шт. Вполне терпимо для начала.
Да ну его, этот мсбилд. У меня проще получилось.
VD>Проблема только в том, что такой подход будет блокировать сборки. Ведь компилятор вынужден подлючать их чтобы считать информацию о типах.
Чего?
АП>>Нельзя ли сделать так, чтобы в этом режиме подгружались ранее не использованные (только что собранные) dll-ки?
VD>Не понял.
Компилирую одну сборку, пусть с макросами, а потом ее подгружаю и с ее помощью компилирую следующую. Вот чтобы так.
Здравствуйте, Алексей П, Вы писали:
АП>Да ну его, этот мсбилд. У меня проще получилось.
MSBuild — это стандарт. И он исползоуется в VS 2005. Так что ты сразу бы ускорил компиляцию и внутри VS, и ускорил бы сборку компилятора стандартными бат-никами.
VD>>Проблема только в том, что такой подход будет блокировать сборки. Ведь компилятор вынужден подлючать их чтобы считать информацию о типах.
АП>Чего?
Компилятор грузит сборки стандартным образом. Таким обрзом если ты работаешь с двумя сборками, и вторая использует первую (ссылается на нее), то после компиляции второй сборки ты не сможешь повторно скомпилировать первую, так как сборка будте заблокирована.
АП>Компилирую одну сборку, пусть с макросами, а потом ее подгружаю и с ее помощью компилирую следующую. Вот чтобы так.
А в чем проблема? Это должно работать. Только как я уже сказал будут блокировки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>MSBuild — это стандарт. И он исползоуется в VS 2005. Так что ты сразу бы ускорил компиляцию и внутри VS, и ускорил бы сборку компилятора стандартными бат-никами.
Вообще идея. Может и сделаю.
VD>Компилятор грузит сборки стандартным образом. Таким обрзом если ты работаешь с двумя сборками, и вторая использует первую (ссылается на нее), то после компиляции второй сборки ты не сможешь повторно скомпилировать первую, так как сборка будте заблокирована.
Ну это какой-то сложный случай, зачем может понадобиться одну сборку пересобирать два раза за один цикл сборки проекта?
АП>>Компилирую одну сборку, пусть с макросами, а потом ее подгружаю и с ее помощью компилирую следующую. Вот чтобы так.
VD>А в чем проблема? Это должно работать. Только как я уже сказал будут блокировки.
Да нет, не работает. Потому что в ManagerClass.LoadExternalLibraries() написано это:
if (shouldCreate (InternalType.Void)) {
... // загрузка всего
}
else// We use LibrariesManager repeatedly.
LibrariesManager.RemoveInternalExtensionMethods();
То есть при последующих компиляциях состояние LibrariesManager в нужную сторону не меняется.
Здравствуйте, Алексей П, Вы писали:
АП>Ну это какой-то сложный случай, зачем может понадобиться одну сборку пересобирать два раза за один цикл сборки проекта?
Почему за одни? В той же студии можно делать сколько угодно сборок.
АП>Да нет, не работает. Потому что в ManagerClass.LoadExternalLibraries() написано это: АП>
АП>if (shouldCreate (InternalType.Void)) {
АП> ... // загрузка всего
АП>}
АП>else// We use LibrariesManager repeatedly.
АП> LibrariesManager.RemoveInternalExtensionMethods();
АП>
АП>То есть при последующих компиляциях состояние LibrariesManager в нужную сторону не меняется.
Это как раз код кэширования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
АП>>Ну это какой-то сложный случай, зачем может понадобиться одну сборку пересобирать два раза за один цикл сборки проекта?
VD>Почему за одни? В той же студии можно делать сколько угодно сборок.
Ну вот, значит прийдется ловить какое-то событие вроде "начата сборка проекта" и сбрасывать кэш по нему. Я не знаю, есть ли такое событие, но если нет, можно попробовать ловить по истории сборки — например, если пытаемяся второй раз что-то собрать, значит надо сбросить.
У меня в утилите таких проблем просто нет, т.к. она command-line only. Для SciTE — определяет, что пересобрать, по имени файла.
АП>>Да нет, не работает. Потому что в ManagerClass.LoadExternalLibraries() написано это: АП>>
АП>>if (shouldCreate (InternalType.Void)) {
АП>> ... // загрузка всего
АП>>}
АП>>else// We use LibrariesManager repeatedly.
АП>> LibrariesManager.RemoveInternalExtensionMethods();
АП>>
АП>>То есть при последующих компиляциях состояние LibrariesManager в нужную сторону не меняется.
VD>Это как раз код кэширования.
Ага, вот еще бы при этом кэшировании в LibrariesManager добавлять сборки, которых не было в списке при его предыдущем использовании.
Здравствуйте, Алексей П, Вы писали:
АП>Ну вот, значит прийдется ловить какое-то событие вроде "начата сборка проекта" и сбрасывать кэш по нему. Я не знаю, есть ли такое событие, но если нет, можно попробовать ловить по истории сборки — например, если пытаемяся второй раз что-то собрать, значит надо сбросить.
Компилятор в нашем распоряжении. Так что событие прикрутим. Это не проблема.
Проблема в блокировках. Прийдется писать код ручной загрузки сборок (через массивы байтов). Это сразу вызовет проблему разрешения типов, так как для загруженных таким образом сборок дотнрет не производит разрешение имен.
Мы еже говорили об всем этом с компиляторщиками, они даже выделели этот код в виртуальные методы.
АП>У меня в утилите таких проблем просто нет, т.к. она command-line only. Для SciTE — определяет, что пересобрать, по имени файла.
Понятно. В МСБилдовском таске тоже пока таких проблем нет, но только потому, что он использует компилятор командной строки. Ну, а это замедляет процесс компиляции.
Причем если обычные проекты замедляются не так сильно, ведь компилятор при этом приджитнут, то компиляция кода компилятора тормозится очень сильно, так как каждый проект вызвает джит-компляцию компилятора. По моим наблюдениям на маленьких проектах время джита составляет 97% от времени работы компилятора. Я вот даже подумываю не сделать ли возможность использовать преджитнутый компилятор для сборки компилятора.
АП>Ага, вот еще бы при этом кэшировании в LibrariesManager добавлять сборки, которых не было в списке при его предыдущем использовании.
Дык, все в наших руках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
