Почему мои тесты Yesod выполняются параллельно намного медленнее?

#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 только количество фактических ядер, а не количество гиперпоточных виртуальных. Нет, я не знаю почему.