This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Parser keep a lot of equals strings. For example profiler shows that in project "chromium": - 282 equals strings "phajdan.jr@chromium.org". - 25520 equals strings "true". - 21280 equals strings "file". - 193 equal string "2009-10-22T20:02:37.997393Z" ... All strings belong to subversion.client.parser.EntriesCache Do subversion need to keep all entries in memory? If needs consider optimization of data structure: - do not keep equals strings - replace use primitive Java types for storing boolean and timestamps. All size of subversion.client.parser.EntriesCache in project "chromium" is 34Mb.
maybe i'm missing something, but for now i don't think its obvious that fixing this (32mb!) issue is really holding you off from solving the >1G problem in 171672. So what exactly is it that blocks you? The 32 to 1000 footprint ratio? please explain or be reasonable. thanks
few more things: - this happens only when the subversion module is running with the svn cli. Many clients don't do that and for those which do a possible workaround would be to use javahl - see http://wiki.netbeans.org/FaqSvnJavahl for more info. - considering the bug priority guidelines - the mentioned 34mb in your setup which caused the ide to grow over 1G doesn't seem to be a justification for a P2.
Let me explain my point of view. User expectation is "Create and Parse chromium project in 512Mb of heap". By the way it is default heap. CND side did a lot of memory improvement since NB6.7. Now the project can be created and parsed in 600Mb of heap. IDE still has to reduce memory consumption on 100Mb. Subversion is an obvious and a low hang fruit that can save 32Mb from needed 100Mb. IMHO it is a good enough reason to restore P2 priority and add dependency on BZ#171672. By the way your reference on "http://wiki.netbeans.org/FaqSvnJavahl" does not have any sense because IDE does not provide any notification about this problem. So the reference is "internal suggestion of future improvement of subversion". Does subversion have any plans to bundle needed binaries/libraries (or automate process of downloading/building/installing needed software) in NB6.9? If subversion has such enchantment you can close bug as duplicated.
Again, i can't see why this one should be a blocker for 171672. We are dealing here with two different problems for which we got two different issues: 1.) the memory problems in cnd (171672) 2.) the memory problems in the svn parser cache (181505) Is there anything in issue 181505 that prevents the cnd team to fix the part in the cnd project? Or are there already some fixes provided by the cnd team (even if not mentioned in 171672!) which won't have effect until 181505 gets fixed? Because otherwise i just don't understand why we shouldn't treat 171672 and 181505 as too independent issues. What exactly is it in 181505 that _BLOCKS_ you from closing 171672? > CND side did a lot of memory improvement since NB6.7. > Now the project can be created and parsed in 600Mb of heap. then why isn't it mentioned in #171672? or at least, why wasn't it mentioned in this one? is it mentioned in some other issue? shouldn't be rather that issue be the blocker for #171672? > By the way your reference on "http://wiki.netbeans.org/FaqSvnJavahl" does not > have any sense well, the main reason was to provide additional and eventually useful information about the scenario and a possible workaround. Actually, that's what the whole paragraph was about - to provide an as complete picture about the problem as possible. Hope that makes sense now.
for the fix: - canonalize the strings kept in the parser cache to avoid multiple instances for the same value. - put a limit on the cache size so it won't grow for ever
(In reply to comment #4) > Again, i can't see why this one should be a blocker for 171672. We are dealing > here with two different problems for which we got two different issues: > 1.) the memory problems in cnd (171672) > 2.) the memory problems in the svn parser cache (181505) Actually all IDE subsystem share common heap (512Mb). Java VM (and especially editor) need some constantly free heap. Let it be 150Mb. Rest heap (362 Mb) is shared between IDE platform and CND. IMHO rest memory should be divided on two part: - platform (181Mb) - CND (181Mb) because C/C++ project is opened. But on chromium project platform eats more then 181Mb (about 320Mb). Hence blockers of 181505: - file system that consumes 120Mb on chromium project. - NB platform that keeps a several equals file/folders names in heap and pool. - module system that keeps 2,3 till to 20 equals modules names in heap and pool. - version system that keeps a lot of duplicated strings and store primitive types in strings. ... Platform have to reduce memory consumption on 140Mb. It is a*blocker* for the 171672. Do you agree?
http://hg.netbeans.org/cdev/rev/8cfc5da2f869 fixed
depending on scenario: - reduced amount of held string instances 6 - 10 times - reduced occupied memory 2 - 4 times
Great, thanks a lot.
Hi Tomas. I can not find your commit in main-silver repository, but it is not available by provided link http://hg.netbeans.org/cdev/rev/8cfc5da2f869 as well => should reopen
it's not pushed yet
Verified: - memory reduced from 34Mb to 5Mb. Good result!