#haskell #ghc #yesod
#haskell #ghc #yesod
Вопрос:
На машине с 8 виртуальными ядрами time .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/test/test RTS -N1
отчеты:
real 0m10.368s
user 0m8.592s
sys 0m2.056s
Пока time .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/test/test RTS -N8
отчеты:
real 0m15.266s
user 0m40.032s
sys 0m19.880s
Чтобы воспроизвести: запустите stack new partest yesod-simple
, добавьте replicateM_ 500
к test/Handler/HomeSpec.hs
after describe "Homepage"
и установите ghc-options
в partest.cabal
to -Wall -rtsopts -threaded
.
Почему это так? Я думаю, что это должно выиграть от параллелизма — я не могу придумать никаких ресурсов, за которые потоки будут бороться. yesod-test
даже не запускает реальный сервер. Удаление загрузки файла из теста существенно не влияет на результаты.
Это свернутый пример. Моя первоначальная проблема заключается в более крупном приложении, где кажется, что прохождение -N
вообще не приводит к параллельному выполнению тестов. Итак, мой другой вопрос: есть ли в Yesod что-то, что предотвращает параллелизм? Одновременный доступ нескольких потоков к БД приведет к аннулированию некоторых тестов, но я хотел бы решить эту проблему самостоятельно. (В yesod-simple
шаблоне нет базы данных, так что это не может быть проблемой.)
Комментарии:
1. Я мало что знаю об этом, но мне дали понять, что обычно вы должны сообщать GHC только количество фактических ядер, а не количество гиперпоточных виртуальных. Нет, я не знаю почему.