Ускорит ли запуск всего с RAM-диска время компиляции scala?

Сценарий:

Машина, которую я использую для разработки, имеет 32 ГБ оперативной памяти DDR3, i7 3770, SSD. Проект большой, Scala быстро компилируется большую часть времени во время инкрементной компиляции, но иногда одно изменение приводит к перекомпиляции сотен файлов, затем требуется некоторое время для компиляции всех и некоторое время для jrebel для перезагрузки всех измененных файлов.

Вопрос:

Сделает ли размещение всего на RAMFS (Mac) компиляцию и перезагрузку jrebel значительно быстрее?

Мой план состоял в том, чтобы поместить все, что непосредственно связано с проектом, в раздел RAMFS (.ivy, исходный код проекта, .sbt, возможно, даже скопировать JDK и т. д.). Я бы создал скрипт, чтобы делать все это в загрузке или вручную, это не будет проблемой. Кроме того, я бы настроил задачи синхронизации файлов, поэтому потеря изменений не будет проблемой в случае сбоя ОС.

Обновления:

  1. log говорит, что около 400 исходников java и scala скомпилированы после очистки.
  2. после изменения файла в модуле ядра он перекомпилирует 130 файлов за 50 секунд.
  3. jrebel перезагружается за 72 секунды после № 1 и 50 с после № 2
  4. добавление -Drebel.check_class_hash=true сделало мгновенную перезагрузку jrebel после # 2.

Я очень доволен этими результатами, но все еще заинтересован в том, чтобы сделать компиляцию scala еще быстрее, поскольку загрузка процессора достигает не более 70% всего за 5 секунд в процессе компиляции, который занимает 170 с, общее использование процессора во время компиляции составляет 20%.

ОБНОВИТЬ:

После размещения папок JVM, source, .ivy2 и .sbt на RAMDISK я заметил небольшое улучшение только времени компиляции: со 132 до 122 с (после очистки). Так что не стоит хлопот.

ПРИМЕЧАНИЕ:

Это исключает разрешение зависимостей, поскольку я использую этот подход чтобы не потерять разрешение зависимостей после очистки.


person Johnny Everson    schedule 24.11.2012    source источник
comment
Что произойдет, если компьютер выйдет из строя? Можно ли разбить проект на компоненты и разрабатывать их по отдельности, чтобы не было сотен строк? т.е. каждый компонент разрабатывается и тестируется, а затем создается и упоминается как JAR, а не как проект с исходными кодами.   -  person Ant Kutschera    schedule 24.11.2012
comment
1. настроит задачу для резервного копирования исходных файлов каждую минуту или около того. 2. Изменение структуры проекта невозможно.   -  person Johnny Everson    schedule 24.11.2012
comment
Какая у вас IDE? У вас включен FSC? Инструкции IntelliJ blog.jetbrains.com/scala/2011/10 /05/real-fsc-support Это дало мне самый значительный прирост производительности компилятора. Я не совсем уверен, что предельная выгода от ramdisk компенсирует любые головные боли при его настройке / обслуживании. Может быть, все еще интересно попробовать (и развернуть аккуратный инструмент для). В прошлом я делал что-то подобное с большим Java-проектом на Windows 7 с небольшим заметным улучшением (SSD уже преодолел большую часть разрыва).   -  person Jason Dunkelberger    schedule 24.11.2012
comment
Интеллектуальная идея. Но меня больше всего беспокоит не время компиляции, а время перезагрузки jrebel для работающего приложения Lift.   -  person Johnny Everson    schedule 24.11.2012
comment
Почему не только бинарники в RAMFS? Бьюсь об заклад, чтение источников довольно быстро.   -  person pedrofurla    schedule 24.11.2012
comment
имеет смысл, но, поскольку это проект sbt с несколькими подпроектами, двоичные файлы разделены на несколько каталогов /target. Тем не менее, все еще кажется хорошей идеей. Благодарю.   -  person Johnny Everson    schedule 24.11.2012
comment
Я вообще скептически отношусь к решениям на основе ramdisk. Кажется, что делать то, что ОС должна делать в любом случае, очень сложно — кэширование часто используемых файлов в памяти после первых нескольких обращений.   -  person Andrew Gorcester    schedule 24.11.2012
comment
почувствуйте свою боль, не ограничиваясь Лифтом. Я подозреваю, что все страдают от блюза времени сборки. Могу я спросить, сколько файлов Scala у вас есть в вашем проекте и каков самый продолжительный результат инкрементной сборки с одним изменением кода?   -  person virtualeyes    schedule 25.11.2012
comment
@AndrewGorcester, как ОС должна кэшировать двоичные файлы, которые пишет компилятор?   -  person pedrofurla    schedule 25.11.2012
comment
@JhonnyEverson, еще одна вещь, которая может улучшить или не улучшить скорость, - это наличие зависимых банок в RAMFS, возможно, завышенных.   -  person pedrofurla    schedule 25.11.2012
comment
Я думаю, что немного знаком с вашим бедственным положением. :) См. также: stackoverflow.com/questions/11587255/ Одна вещь, которую я подозреваю, является распространенной проблемой: сборки Scala агрессивно перекомпилируются из-за возможности того, что изменение видимости отразится на сборке (неявное разрешение и т. д.). Временная метка файла .class изменяется, но не хэш. JRebel, похоже, на 100% отличается от временной метки, если бы вы могли добавить шаг, который проверял бы хэш .class и перезаписывал его только в случае его изменения, вы могли бы уменьшить время JRebel.   -  person cldellow    schedule 25.11.2012
comment
@pedrofurla Я надеюсь, что запись будет записана в быстрый кеш, а затем лениво записана на диск, но, возможно, в данном случае это нереально, учитывая объем рассматриваемых данных. Я считаю, что виртуальные диски не элегантны, и для этой проблемы должно быть решение на уровне ОС, но, возможно, его просто нет, и единственным выходом является виртуальный диск.   -  person Andrew Gorcester    schedule 25.11.2012
comment
@virtualeyes в журнале sbt указано около 400 среди источников java и scala. После изменения файла в основном модуле он перекомпилирует 130 файлов. jrebel требуется 50 секунд, чтобы перезагрузить эти изменения. Извините, что слишком долго не отвечал. Вдали от компьютера разработчика.   -  person Johnny Everson    schedule 25.11.2012
comment
Я сделал, как предложил @cldellow, добавив -Drebel.check_class_hash=true, чтобы перезагрузить jrebel очень быстро после всех этих перекомпиляций. Тем не менее, для компиляции sbt требуется 50 секунд после единственного изменения в файле ядра. Остается вопрос. Попробую это в ближайшее время.   -  person Johnny Everson    schedule 25.11.2012
comment
Ой, лучшее, что вы собираетесь получить с точки зрения производительности, можно найти в Scala 2.10 + SBT 0.13; даже тогда маловероятно, что вы почувствуете, о, это так быстро. Мы платим цену за совершенство Scala. Очевидно, FSC и высокая тактовая частота процессора очень полезны; то есть двухъядерный процессор с частотой 3,8 ГГц должен компилироваться быстрее, чем четырехъядерный процессор с частотой 2,8 ГГц.   -  person virtualeyes    schedule 26.11.2012
comment
Я бы хотел, чтобы каждая компания предоставила своим разработчикам такое оборудование.   -  person sunsations    schedule 27.11.2012


Ответы (3)


Я понятия не имею, какое ускорение вы можете ожидать от Mac, но я видел ускорение в Linux при компиляции самого компилятора Scala, которое достаточно обнадеживает, чтобы попробовать. Мой отчет (предупреждение: довольно специфичный для Linux) там.

person Francois G    schedule 04.07.2013

Вы можете попробовать установить аргумент виртуальной машины -Drebel.check_class_hash=true, который будет проверять контрольную сумму перед перезагрузкой классов.

person Anton Arhipov    schedule 26.11.2012
comment
обновленный вопрос уже сообщает результат с этим флагом. Это частично решает проблему. Время компиляции по-прежнему велико. Все еще интересует информация о запуске всего стека из ОЗУ, что я вскоре попробую, если кто-то не покажет, что это бесполезно. - person Johnny Everson; 27.11.2012

В RAM-диске часто очень мало смысла, если вы работаете в Linux или OSX. Эти ОС все равно кешируют файлы.

https://unix.stackexchange.com/a/66402/141286

person Oliver Shaw    schedule 02.09.2016