wondering if anyone else is experiencing unusably slow Intel

Question

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 amp 64GB RAM 4GB heap for IntelliJ

sam · Answer

are you using the init block or lambda constructor

Peter · Answer

the init block

sam · Answer

how many tests in a file version of intellij and what version of kotest

Peter · Answer

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

sam · Answer

basically same as me

sam · Answer

is it only word spec that s slow

Peter · Answer

i haven t tried others to be honest this is my preferred spec coming from scalatest i ll give it a whirl

Peter · Answer

would the lambda constructor be preferable

sam · Answer

I don t think so I ve just seen some people say that the lambda constructor is slow and the init block fast

Peter · Answer

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

sam · Answer

can you try making a copy of the file with just the outline of the tests

sam · Answer

<https github com kotest kotest issues 1473> lt about the constructors

Peter · Answer

sure let me take a look

wasyl · Answer

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

wasyl · Answer

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

sam · Answer

do we know when 1 4 20 is due out

Peter · Answer

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

sam · Answer

kotlintest is faster than kotest

sam · Answer

or did you mean kotlin test

Peter · Answer

correct disappointed

Peter · Answer

kotlin test takes about 2 3 seconds to reparse analyze a new block of code while kotest it takes gt 1 minute

Peter · Answer

the same proportion is reflected in code completion

sam · Answer

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

sam · Answer

It would be a shame if you have to abandon kotest for junit and write tests in such a limited way

thanksforallthefish · Answer

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

Peter · Answer

FYI logged issue here <https youtrack jetbrains com issue KT 42563>

sam · Answer

Looks like they think its related to geenrics

Peter · Answer

right which is the same the person earlier in this thread mentioned

sam · Answer

Yeah

sam · Answer

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

sam · Answer

Makes sense that it s all related to generics

Peter · Answer

an aside have you been following the Arrow Option drama wink

sam · Answer

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

Peter · Answer

community follow up <https github com arrow kt arrow core issues 238>

sam · Answer

interesting I prefer options to

Peter · Answer

100000000

sam · Answer

You lose the ability to nest nulls with which is a limited use case I suppose

sam · Answer

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

sam · Answer

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

Peter · Answer

that makes sense very cool