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.
Product Version: NetBeans IDE 6.7.1 (Build 200907230233) Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16 System: Linux version 2.6.28-15-generic running on i386; UTF-8; en_US (nb) Userdir: /home/radim/.netbeans/chromium Follow http://code.google.com/p/chromium/wiki/LinuxBuildInstructions to install prerequisities and get the code. Than build it using scons and also generate Makefiles (http://code.google.com/p/chromium/wiki/LinuxMakeBuild). Now the source code is 1.6G+ and the whole build tree is ~10G. Let's wrap it into NetBeans project - use custom setting to avoid clean & build and select source root. The result is a long time of CPU and disk activity. I waited 30+ minutes and there was no sign that this is going to end soon and the IDE breathed in a very small chunk of heap and and GC had very hard time. During this time IDE threw some OOMEs. I quit it complete then. I did the same with -J-Xmx1024m and this passed. The result is not great though: 13mins to analyze sources and then another 8 minutes to parse 8500+ files. And this is followed immediately with another 9 minutes of parsing! Why the hell it is parsing twice. Open randomly some file and add include dir to a project to fix some parsing errors and another 7+ minute of parsing. Even the 1G setting seems too small - the memory usage never got below 750M-790M. Do I really have to have more than 1G heap to setup a project with 1.6G of sources?
BTW: hw spec for my machine is Dell Latitude E6500 / 4GB RAM / Intel Core 2 Duo P8700, 2.53GHz / 250GB HDD 7200rpm ... 30 minutes to setup a project is a lot of time.
We know about performance and high memory footprint. we reduced memory usage twice in 6.7 comparing with 6.5 and more improvements are expected further. What we can address in this release is the useless second parse during project creation. Btw if you compile with CFLAGS="-g3 -gdwarf-2" CXXFLAGS="-g3 -gdwarf-2" => IDE should detect needed #include directives
other tip to speed up "project creation" phase for big projects. give IDE 2Gb for this period and use 32bit JVM + again compile with extra debug info CFLAGS="-g3 -gdwarf-2" CXXFLAGS="-g3 -gdwarf-2"
Thanks for the feedback. To respond: it is 32-bit JVM (I can double check later). Does the hint with CFLAGS make any difference if this project is built with SCons and all the Makefiles are only created to make an input for CND project?
http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem - some info about Scons and this project
Please waive it for 6.8
Following memory improvements were done: - reduce peak of memory at parsing time (reduce on 30%) changeset dcc716ac8242 in cnd-main changeset b2de96b528a7 in cnd-main changeset 31cf12e47250 in cnd-main changeset 6341ab6b7bf0 in cnd-main changeset 97f556a798fd in cnd-main changeset d00ae656db01 in cnd-main - Exclude discovered by make log assembler files from C/C++ code model (remove 170Mb peak at parsing time) changeset 968f39adb96c in cnd-main - migrate source data objects from CookieSet to Lookup (reduce size of data objects in 4 times, save about 30Mb) changeset 417a04264133 in cnd-main changeset 76ec516eaef9 in cnd-main changeset d51cd1838919 in cnd-main changeset 6dcb0d8225b9 in cnd-main changeset 3054ed9b338a in cnd-main - add char sequence key class for strings with length from 16 to 23 (save about 1.2 Mb) changeset 54c5d9342900 in cnd-main - reduce size of IntConfiguration (save about 1 Mb) changeset 74c561050bfc in cnd-main - reduce size of BooleanConfiguration (save about 2 Mb) changeset 4eea2360884e in cnd-main
(In reply to comment #0) > I did the same with -J-Xmx1024m and this passed. The result is not great > though: 13mins to analyze sources and then Discovery issue is tracked in the BZ#171937 Analyzing performance depend on performance of your disk system. > another 8 minutes to parse 8500+ files. And this is followed immediately with > another 9 minutes of parsing! Why the hell Bug already was fixed. > it is parsing twice. Open randomly some file and add include dir to a project > to fix some parsing errors and another 7+ Unfortunately this behavior is C/C++ specific. If you change user defined paths for all sources files IDE have to reparse all sources. You should avoid to setup manual project properties. For this exist "configure code assistance". Configuration can analyze: - binary files that compiled with "-g3 -gdwarf-2" flags - make build log > minute of parsing. Even the 1G setting seems too small - the memory usage never > got below 750M-790M. Now development version of NB can do it in 600Mb. Next improvements depend on NB platform improvements. Obvious memory improvements is: - NB platform consume about 300Mb of heap. - file system a biggest memory consumer 120Mb on chromium project. - NB platform keep a several equals file/folders names in heap and pool. - editor need more then 20 bytes memory on each byte of editing file. - version system keep a lot of duplicated strings and do not try to store primitive type instead strings (see BZ#181505). My estimation show: - NB platform memory consumption should be reduced on 100-150Mb - Editor should reduce overhead charges from 20 to 3 bytes on each editing byte.
Alexander, I feel you need to waive this bug one more time or lower priority. Whatever you think is more appropriate. It does not look as we have resources to fix it in 6.9. We may want to make it a feature for next release.
IMHO CND has good enough memory consumption. Problem is in IDE subsystems: - scanning - file system It is a static i.e. "startup, parsing, scanning" problem. I hope that IDE solves problems in NB6.9 Other problem is "dynamic" IDE behavior i.e. editor with all features (highlighting, hyper linking, find usages, refactoring). Definitely editor consume a lot of memory. IMHO it cannot be fixed in NB 6.9. But if IDE core and CND support share about 300Mb IDE editor will be good enough. So I would prefer to waive issue late if IDE does not fix 181684.
fixed