Open marioja opened 6 years ago
STS configuration.txt This file contains the STS configuration
This sounds indeed bad, I agree. I wonder why this is slower than 3.8.x versions of STS though. But lets try to find this out. There are a few steps that we can take to identify the performance issues in more detail:
Would be awesome if you could spend a bit of time to provide these details. Would really like to dive into the details here to see what is going wrong here.
(oh, and sorry for being so late in responding here, would like to apologize for that)
Any update on this? I have the spinning beach ball of death (Mac) for every mouse event in the editor - STS v3.9.3, all validations off, content assist on (cleared cache and indexes), memory at 1024m/2048m.
@kaaterskil it would be great if you could take a look at the comment above and maybe provide some more details (using the described methods), that would be awesome. Would help a lot to find out what is going wrong on your side. The behavior you describe is clearly not what I am seeing on my Mac, so there must be something specific that we need to identify.
"I have the spinning beach ball of death (Mac) for every mouse event in the editor" I have the same issue with STS 4. My mac specs are great btw but still the IDE is so slow and it eats the cpu! It's worst experience I had so far with any IDE.
@uloga It sounds like you are running on STS 4.x, for which we use a different project on GitHub, so it would be great if you could report the issue here: https://github.com/spring-projects/sts4/issues
When reporting it would be awesome to include a few steps how to reproduce this and maybe also provide a sample project (in case this happens using a specific workspace or project). The spinning beach ball of death definitely sounds like there is something blocking the UI thread that should not and needs investigation. So please report this over at the STS4 tracker.
Also, if possible, it would be awesome if you could capture a thread dump (using jps
and jstack
) at exactly the time when the beach ball is running and eating your CPU, it might reveal the root cause of this right away for us.
The following elapsed time measurements were taken on Windows 10 on an AMD Phenom II X4 920 Processor 2.80 GHz processor with 8GB of ram and STS installed on solid state disks. STS.ini uses the following to start STS:
The first number is the elapsed time in seconds (or minutes:seconds) since the previous bullet or since the start of the test. Three separate tests were run. For example, in the next test, the progress bar started updating 32.6 seconds after the workspace name was entered. The STS window appeared 7.1 seconds after the progress bar started updating.
new workspace called wsp1
open existing blank ws wsp1
restart existing wsp1
switch to existing ws with 9 maven java projects
These times are really not acceptable. I chose this tests because they do not require test projects or data.