Summary: | [compiler] Memory-extensive computation of Binding.computeUniqueKey() slows down editing of large files | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Lukas Eder <lukas.eder> | ||||||||
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||||||
Status: | REOPENED --- | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | stephan.herrmann | ||||||||
Version: | 4.6 | Keywords: | performance | ||||||||
Target Milestone: | --- | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows 10 | ||||||||||
Whiteboard: | stalebug | ||||||||||
Attachments: |
|
Description
Lukas Eder
2017-06-02 07:11:51 EDT
Created attachment 268712 [details]
Allocation pressure
Created attachment 268713 [details]
Stack trace for char[] allocations
Created attachment 268714 [details]
Stack trace for TypeBound[] allocations
While compilation is still slow, I cannot reproduce the allocations that I've reported at the time when using 4.7.1a This means that this particular problem has either been fixed (and wasn't so significant), or it was only a symptom of a bigger problem, which exposes itself elsewhere now. I'm closing this to avoid the noise of having it open, reporting a new issues instead. I was wrong, sorry. I can still reproduce the TypeBound[] allocations originating from the BoundSet constructor. It's just that there are now other memory-intensive allocations happening, which seem to further worsen compilation speed. Just linking the dots regarding one observation: (In reply to Lukas Eder from comment #0) > Some analysis on TypeBound[]: > ----------------------------- > > The memory consumption here is also excessive, and it all happens inside of > org.eclipse.jdt.internal.compiler.lookup.BoundSet() > > This class is created quite a few times through the copy() method, and each > time it allocates an array unincorporatedBounds of size 1024. Is this really > necessary? This was introduced via Bug 442245. Could mean we are trading cpu vs. memory. I'm not aware of any measurement justifying the 1024. @Lukas, can you give simple instructions for me to setup an environment in which i can compile your DSL.java from comment 0 (ideally without maven or such)? Alternatively, could you repeat your measurements from an I-build after we reduced the size of the suspicious array? Sure, here's a copy of the Github repository with only the relevant code inside, and without Maven: https://github.com/lukaseder/jOOQ-Eclipse-Bug-517703 I'm using JDK 1.8.0_141 to build this. I can reproduce similar signatures in JMC's memory allocation views, even if the UI feedback is a bit faster with the reduced amount of code (and without Maven). Let me know if you need anything else. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |