https://kotlinlang.org logo
Join Slack
Powered by
wondering if anyone else is experiencing unusably ...
# kotest
p
wondering if anyone else is experiencing unusably slow IntelliJ performance, especially in kotest specs (WordSpec in this case)? by slow I mean more than a minute for type completion to pop up … on a machine with i9900k CPU & 64GB RAM (4GB heap for IntelliJ)
s
are you using the init block or lambda constructor
p
the init block
s
how many tests in a file, version of intellij, and what version of kotest ?
p
21 tests, 786 lines total IJ IntelliJ IDEA 2020.2.3 (Ultimate Edition) Build #IU-202.7660.26, built on October 6, 2020 azul JDK 11.0.8 Kotest 4.2.5
s
basically same as me
is it only word spec that's slow ?
p
i haven’t tried others to be honest, this is my preferred spec coming from scalatest … i’ll give it a whirl
would the lambda constructor be preferable?
s
I don't think so, I've just seen some people say that the lambda constructor is slow and the init block fast
👍 1
p
also one more thing that may have an impact, there is probably 100-200 extension functions in scope … i’ve wondering how that would impact intellij but haven’t found any indications anywhere
s
can you try making a copy of the file with just the outline of the tests ?
p
sure let me take a look
w
Constructor used to be super slow and has since been fixed, afair (I was one of the people reporting it). Still, we moved to init blocks and it's insanely slow, close to being unusable. I opened some issues on Youtrack and I'd suggest doing the same (using Performance Testing plugin). Supposedly some of the problems are fixed in 1.4.20, too. You may try moving to preview channel and seeing if some newer Kotlin plugin helps.
My feeling is that specs lambdas aren't problematic in themselves, but if you start adding generic methods (so also mocks) then the performance tanks. I haven't had time to properly investigate this, though, so that's just a guess.
s
do we know when 1.4.20 is due out ?
p
thanks, I did start a report. btw - I just conducted another experiment, reverted the test back to junit/kotlintest and it’s performance is many orders of magnitude faster
s
kotlintest is faster than kotest ?
or did you mean kotlin.test
p
correct 😞
kotlin.test takes about 2 - 3 seconds to reparse/analyze a new block of code, while kotest it takes > 1 minute
the same proportion is reflected in code completion
s
If it's a problem with the DSL structure of the tests, then if you use FunSpec you will get all the benefits of Kotest (coroutine integration etc) and there should be no slow down. Or alternatively there's AnnotationSpec which is basically just junit style.
👍 1
It would be a shame if you have to abandon kotest for junit and write tests in such a limited way
💯 2
t
I have a similar experience (slowness) with junit. It seems a generic performance problem in intellij, everybody gets a different personal configuration that somehow allows to progress work. youtrack is full of reports
p
s
Looks like they think its related to geenrics
p
right, which is the same the person earlier in this thread mentioned
s
Yeah
I used to have issues with arrow in similar way, because I write my code using functional data types such as Eithers and so on
Makes sense that it's all related to generics
p
an aside, have you been following the Arrow Option drama? 😉
s
I know they planned to remove Option but that was as far as I got. I've stopped using Arrow recently in favour of my home grown types.
p
s
interesting. I prefer options to ?
p
100000000%
s
You lose the ability to nest nulls with ?, which is a limited use case I suppose
I can't use arrow in the public projects because it changes drastically on each release and means anyone using it in their own projects, then gets into a clash with kotest. So I spun up my own dependency free, mpp, data types for either, option, try and io
So then users of kotest can use arrow in their own projects, and upgrade arrow at will, and there's no risk of a clash
p
that makes sense, very cool!
49 Views
Open in Slack
PreviousNext
Powered by