PerformanceProblemsRawInput

NB 6.0 Main Performance Problems

Contents


This page collects raw data about main performance problems present in NetBeans 6.0, perceived from the user's point of view. Things like "bad architecture" or "support for XXX should be initialized lazily" is not what we want in the first place. At this point we are primarily interested in what affects the user directly, what problems they must face when working with the IDE. But it can still be useful to mention an underlying problem as a cause of the user problem.

  • Please add the issues you know about into the categories below. We are mainly interested in the first category.
  • Feel free to upgrade priority of already entered problems. Add your own comment, or even enter the same thing again with your description if you feel it is really important.
  • Please state priority (if known) of each problem or criteria you mention.
  • Use the Other category if you know about a problem that is worth mentioning but does not fit the "user point of view" perspective.

A. Performance problems

1. Existing user problems of highest priority (P1, P2)

The biggest existing problems with performance, well known, clear, reproducible.

  • P2: Cold start of the IDE is slow. Takes longer than 5.5, much longer than Eclipse. Waived from 6.0 - IZ 110011
  • P2: Full IDE starts much longer than basic java IDE - startup does not scale with number of modules.
  • P2: Slow start of IDE with opened projects (mainly with apisupport projects).
  • P2: After IDE starts, can't work with java source due to scanning - though in most cases nothing changed from last time.

A user comment: ... improvement would be something to do with startup time. I've accepted the fact that NetBeans takes a while to start. It depends on the machine. It depends on other things. Lots of programs take a while to get going. But my boss tried NetBeans and he had one comment. "It takes a long time to start." And he's right. It's that first impression. I know it's not slow once it starts. I know that it takes a bit to get going for good reasons. But whether it's actually making it faster, or making the startup seem faster or friendlier, I think it would help if it could be improved.

  • P2: Testing changes is slow - executing application after doing a small change, also using run/debug single file; rebuilding the project is slow (mainly compared to competition).

A user comment: ... the performance of a usual cycle "change test -> run and see test fail -> change code -> run and see test succeed" on a single class is still very poor. A long lasting issue of NetBeans compared to others. Digging through the mailing list, you have the option of "turn off dependency check" to speed up the process. But who would want to run that risk?

  • P2: Overall memory consumption - too much memory taken in various situations. E.g. after starting the IDE and opening a project NetBeans seems to consume much memory than in 5.5 and competition. IZ 110015
  • P2: Expanding a package in Explorer is slow and does not scale. IZ 114195, IZ 117179
  • P1: Navigation in explorer/navigator is slow - repetitive actions (e.g. select a file and press down arrow); worse in big IDE.
  • P2: Switching tabs in editor is slow; worse in big IDE (i.e. not scaling).
  • P2: Creating new web projects (with web frameworks, VW) is slow.
  • P2: Problems handling big files in XML editor - memory and performance. Could be investigated for other editors too. IZ 98405, IZ 100520
  • P1: Visual Web - Memory leak problems cause IDE to run out of memory after developing vw projects for some time (< 1 hr). For example, IZ 123003.
  • P2: Visual Web - Drag-and-drop of certain components is slow compared with previous versions. For example, adding a table component to a page took < 1s in Creator 2u1; now it takes 5-10 seconds.
  • P2: Visual Web - Overall "sluggishness" when working with VW projects. Related to the following specific issues:
  • Switching to the design view (from the jsp/java tab or a different page) is slow. Takes several seconds for more complex pages. IZ 123410,IZ 123411
  • Building the project after any form modifications causes Insync to run a sync() command, which takes 8-20s for a relatively small project (12 pages). This sync() causes the IDE to become non-responsive since the work is done in the AWT thread.
  • Opening/closing of a VW page is slow. May be related to the first bullet point.
  • P2: UML performance problems:
  • Slow diagram opening, working with, drawing (heavily linked diagrams) IZ 123518
  • Memory consumption (whole model of the project in memory)
  • Poor performance of reverse engineering into the same UML project repeatedly IZ 111962
  • Slow explorer IZ 123523

2. Existing problems with not-that-high or unclear priority

Known reproducible problems, things that should be done - just don't think they are that important at this moment or don't know how they are important.

  • Evaluation of tooltips among variables in editor during debugging session can be very slow. It can lead to freeze of the IDE especially for huge collections.
  • P2: Memory consumption of the IDE does not scale well. E.g. IDE consumes 130 MB (after GC), all debugging sessions are finished, all windows except projects view and navigator closed, 32 NB projects open.
  • P?: Api support projects are slow. Opening is slow. Building is slow. It consumes huge amount of memory.
  • P3: Java - Performance of initial scan can be improved.
  • P3: Refactoring - Find Usages/Refactoring is slower than competition.
  • Java - Committing of changes to source is slow. (ModificationResult.commit)
  • P3: Java - Performance of code completion can be improved
  • Develop deterministic regression testing
  • Evaluate impact of javadoc completion popup
  • P3: Java - Performance of typing in editor can be improved. We need to test proper canceling of Retouche tasks.
  • Find in Projects - searching large amount of files (>100 files) is slow and may consume a huge amount of memory.
  • P3: Visual Web - New Page creation is slow (5 seconds). The Insync modeling and the initialization of the visual designer contribute to this problem.
  • P3: XML - Opening large XML Schemas in editor is slow. IZ 116806

3. Problems that need more analysis

Potentially significant problems that are not well understood - happen occasionally, under specific conditions, on some specific configurations, or just to some people, etc. More analysis is needed to find out what the problems are, how they really affect the user.

  • JSP

A user comment: The code completion is not a big deal for me, I could disable the autopopup and to Ctrl+space to bring it when I can't remember some sort of spelling. I have a Compaq laptop that has a 789 megaherts AMD semptron processor and I am running Windows XP, I ordered the higher end graphics card and I do not have any problems with NetBeans or GlassFish at all. My co-worker has a 1.8 gigaherts proccessor on a eMachines desktop computer and is running into the problem with a painfully slow JSP editor when scrolling or when pressing enter. We resorted to connecting to my laptop for the Glassfish server because it was not workable to wait for glassfish on the desktop, pressing F6 took something like 30seconds or more. I don't know why. We will do a unconditional restore with the factory CDs--when we have time--to see if that helps, but for now, I don't think NetBeans is going to work :-(. We will disable unused plugins and try disable autopopup and close unused Java Projects. If that does not work we will have to use a second editor. I like NetBeans allot better and I wish they would fix the problem --BaffyOfDaffy

  • There are some complaints and regression reports, that overall performance of the IDE on Windows, especially NTFS is poor. We need to evaluate impact of NTFS fragmentation and handling of huge amount of tiny files on overall IDE performance.
  • Working with 6.0 IDE is much more I/O intensive than it was with 5.5.1 (not due to memory swapping). Especially noticeable with laptops and on Windows.
  • P2: The IDE performance and responsiveness goes down when the IDE is used for longer time. The IDE sometimes runs out of memory.
  • Continuing memory growth, performance degradation...
  • OOMEs in situations where it should not happen - not working with large data.
  • We should find out in what areas and situations (HW&OS, IDE setup, opened projects, used features, etc) we have problems with memory.
  • E.g. reported for opening JSF pages (VWP) IZ 123003.
  • Projects (Java and Web): there is a suspicion about high memory consumption (internal Xerces structures) and memory leaks (not released after closing).
  • P2: Debugging of apisupport projects consumes lot of memory and CPU (not clear if this happens always/to everyone)
  • P1: We suspect that if part of userdir or projects is on some kind of network, then there is a significant responsiveness in performance as well as startup, which can negatively influence enterprise users (like Radim K.), googlefs, nfs.
  • E.g. expanding a package on network is much slower, or switching to/from editor IZ 119415].
  • For network setup also the user dir size is a problem (quotas on home dirs).
  • Slow file opening - IZ 123781

A user comment: To get a 160 line file into the editor took 5 seconds. For that same file to be parsed took an additional 15 seconds for a total of 20 seconds before you could do much with it. I tried the same thing with the same file in eclipse. The total time was less than a second.

  • P2: People say the editor is slow, mainly code completion (see e.g. feedback from NetCAT). Some indications show they often mean JSP editor, but java editor is likely in that as well. Looks like we need numbers (analysis) - e.g. measure CC, typing and navigation in both editors.
  • P2: Creation of some projects/files is really slow.

4. Other

Any other problems you think should be recorded.

  • Web & Java EE area (might be ordered by importance)
  • Visual Web - Runtime performance of J2EE 1.5 components (woodstock) has regressed compared with the J2EE 1.4 components in NB 5.5.1. It is not known how much the new version (available first week of December) of woodstock improves this.
  • Editor - there were problems with scrolling, highlight layers, huge files or files with long lines - all these should be more or less fixed in 6.0; currently Marek Fukala is working on incremental parser of HTML (and JSP we hope) as well as some Schliemann improvements are going to happen in 6.1 Tests for regressions
  • Memory Leaks - e.g. once opened projects stay in memory even if they are then closed IZ 70052 IZ 70172 IZ 85817 IZ 99077 IZ 116292
  • Customizer - saving of a project properties seems to be quite slow (should be solved as suggested in IZ 91291)
  • JSP Parser - quite old, complicated caching, cannot handle includes, the 1st page opening - should be investigated (also affects JSP view in VW), memory leaks IZ 123812 IZ 85817 IZ 71584 IZ 123441 IZ 118123
  • New Web project + Web frameworks - sometimes really slow (about 6 seconds for VW for the first time) - more problem of Web frameworks
  • Loggers - should be added
  • Thread.sleep() - should be removed
  • Add Business Method, Use Database etc. - should be investigated
  • DD Providers - memory leaks, threading
  • XmlMultiView - threading
  • Threading - processing user action is often hampered other things running in other threads. Need to coordinate to make sure UI responsiveness is not blocked - responding to what the user does must be processed preferentially.

B. Performance criteria (critical areas)

Here we collect things (actions, tasks, metrics) that are not necessarily problems at this moment, but they are important for good performance/responsiveness and need to be watched closely. Mainly if there is a risk of regressions (e.g. because not covered by tests).

  • P2: Code completion in Java editor must be fast (appear in 100ms, content under 1s). Content must be updated quickly - to keep up with the user typing.
  • P2: Navigation in editor must be fluent (with no delay) - browsing via keyboard (holding a cursor key), scrolling, jumping, etc.
  • P2: Typing must always have instant response, the editor must keep up with the user.
  • P2: Opening a java file (from explorer, Go to Type dialog, etc) must be within 1 second.
  • P2: Creating mostly used projects and files (web, java) must be fast (specific time limits in particular cases)

C. Comparing to competition

Important tasks suitable to be compared with competition or former releases; tips for things to be included in our comparative dashboard.

  • Real startup scenario (cold startup with opened projects)
  • Opening a java project, web project
  • Building a project
  • Opening a java file, jsp file
  • Code completion speed
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo