Tons of garbage and a minimum of useful work or scrolling in Idea
More recently, when I switched to a new project, I decided to switch from Eclipse to Idea for a change. I already had experience with the idea from version 6, I liked it, but it had a lot of problems. Then I refused it in view of periodic glitches with long work. When I saw that the 11th version was already in the yard, I was delighted and decided to try my luck again, because the interface is a much nicer idea for me ...
About a month ago, I noticed that during active development, when 768 MB of memory allocated for a heap are filled under 80%, any action, such as mouse movement, focus switching, just scrolling with the mouse wheel or directly scrolling in the window causes a large memory consumption and the remaining 20% of memory is eaten in a few seconds of work. Then, of course, you can forget about comfortable work and have to overload the environment due to the constant response of the collector. Today this situation finally got me and I decided to find out - what is the actual problem?
Intuitively, I understood that most likely every movement of the mouse and any action, like scrolling, generates certain events that are then processed, but I did not expect so many of these events. For the seed - 2 screenshots of memory consumption when moving the mouse in the editor window and scrolling inside the open class for 1000 lines:
')
Motion:
Scrolling:
Normal scrolling in the code editing window at the peak eats up almost 100mb of memory in a few seconds ... Any mouse movement generates objects for dozens of megabytes ... The only positive point in all this is that all these objects are then collected.
Naturally, I wondered what this idea generates with such simple actions. So, repeat the experiment:
1.5 million objects for scrolling a little expensive, is not it? But now it became more or less clear where the problem lies. This is a kind of class IntervalTreeImpl and its inner class NodeCachedOffsets. Now we have as many as 2 ways to research: 1) download the IntervalTreeImpl source code and see where and how NodeCachedOffsets are created and why there are so many of them (by the way, many thanks to the developers for the open source codes); 2) Analyze the call stack when scrolling.
I went first in the first way, and then having an idea of what was happening, I analyzed the call stack in order to finally be convinced of the correctness of the conclusions ... So, who cares, you can find the source here . Try to figure it out yourself by looking at the code where the problem lies.
After analyzing the code, it becomes more or less clear what to expect from the call stack, here is its most interesting part:
and
Pay attention to the computeDeltaUpToRoot () method at the very end of the stack and besides it is called quite often and in different ramifications of the stack. In general, having a code, an error on the face - this method is called very often and in many places and at the same time it constantly generates new objects of the problem NodeCachedOffsets class. Obviously, to solve the problem, you just need to get rid of the constant creation of these objects and replace them, for example, with just a large primitive (as an option) or change the approach to drawing the editing window (it requires a lot of refactoring).
In general, here I wanted to beautifully solve the problem and demonstrate its solution, but ... What was my surprise when downloading the latest sources to correct the problem (git: //git.jetbrains.org/idea/community.git), I found that this error has already been fixed, and even 5 months ago ... You can see the fix itself here . It is strange that in the latest version of the idea (11.1.2) there is still no this fix. I would like to get it as soon as possible ... Nevertheless, it is rather pleasant that the guys care about the product.
About a month ago, I noticed that during active development, when 768 MB of memory allocated for a heap are filled under 80%, any action, such as mouse movement, focus switching, just scrolling with the mouse wheel or directly scrolling in the window causes a large memory consumption and the remaining 20% of memory is eaten in a few seconds of work. Then, of course, you can forget about comfortable work and have to overload the environment due to the constant response of the collector. Today this situation finally got me and I decided to find out - what is the actual problem?
Intuitively, I understood that most likely every movement of the mouse and any action, like scrolling, generates certain events that are then processed, but I did not expect so many of these events. For the seed - 2 screenshots of memory consumption when moving the mouse in the editor window and scrolling inside the open class for 1000 lines:
')
Motion:
Scrolling:
Normal scrolling in the code editing window at the peak eats up almost 100mb of memory in a few seconds ... Any mouse movement generates objects for dozens of megabytes ... The only positive point in all this is that all these objects are then collected.
Naturally, I wondered what this idea generates with such simple actions. So, repeat the experiment:
1.5 million objects for scrolling a little expensive, is not it? But now it became more or less clear where the problem lies. This is a kind of class IntervalTreeImpl and its inner class NodeCachedOffsets. Now we have as many as 2 ways to research: 1) download the IntervalTreeImpl source code and see where and how NodeCachedOffsets are created and why there are so many of them (by the way, many thanks to the developers for the open source codes); 2) Analyze the call stack when scrolling.
I went first in the first way, and then having an idea of what was happening, I analyzed the call stack in order to finally be convinced of the correctness of the conclusions ... So, who cares, you can find the source here . Try to figure it out yourself by looking at the code where the problem lies.
After analyzing the code, it becomes more or less clear what to expect from the call stack, here is its most interesting part:
and
Pay attention to the computeDeltaUpToRoot () method at the very end of the stack and besides it is called quite often and in different ramifications of the stack. In general, having a code, an error on the face - this method is called very often and in many places and at the same time it constantly generates new objects of the problem NodeCachedOffsets class. Obviously, to solve the problem, you just need to get rid of the constant creation of these objects and replace them, for example, with just a large primitive (as an option) or change the approach to drawing the editing window (it requires a lot of refactoring).
In general, here I wanted to beautifully solve the problem and demonstrate its solution, but ... What was my surprise when downloading the latest sources to correct the problem (git: //git.jetbrains.org/idea/community.git), I found that this error has already been fixed, and even 5 months ago ... You can see the fix itself here . It is strange that in the latest version of the idea (11.1.2) there is still no this fix. I would like to get it as soon as possible ... Nevertheless, it is rather pleasant that the guys care about the product.
Source: https://habr.com/ru/post/147552/
All Articles