PostSixOhPerformanceTopics

Revision as of 18:13, 18 February 2010 by Tpavek (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

Topics for post-6.0 performance work

NetBeans Fitness program implications for future releases.

For 6.1:

  • MIME resolution: issue 117319
  • LookupCoalescer API from 117319?
  • Provide MIMEResolvers for all common types so they don't end up being examined by last check-all sniffing resolvers
  • Cold start improvement (reduce I/O): keep the module database in single file instead of 550 as we do currently
  • Fix modules depending on deprecated modules, remove deprecated modules from distro
  • With the help of jrechtacek's dependency auto-download
  • Editing: continue to investigate possible performance improvements in the Schliemann infrastructure and in the editing of embedded languages (JSP, HTML, RHTML, ...)
  • Optimization of projects-on-network usecase
  • Removing the support for the obsolete VCS Generic in filesystems infrastructure
  • Web & Java EE: Make GlassFish v3 (or Tomcat) the default server instead of v2. This will improve server startup time and speed up the Java web app development cycle for the default out of the box configuration. It will also decrease memory usage in web development scenarios.

For 7.0:

  • Startup time improvements
  • Different module format, probably single large file with necessary startup resources (locally generated/optimized). The additional disk space usage can be offset by compressing module jars.
  • Parallelize the startup sequence in a controlled way. By the 7.0FCS, everybody will have dualcore, at least.
  • DataLoaders improvements, top-down and bottom-up
  • Analyze specifics of why everybody subclasses EditorSupport, DataNode, DataObject and DataLoader
  • Top-down:
  • Provide good-enough EditorSupport factory/implementation that would eliminate most of subclasses
  • Provide good-enough DataNode that would eliminate most of subclasses
  • Provide generic pluggable DataLoader/DataObject pair that most modules can use
  • Bottom-up:
  • Move Loaders from manifest sections to Lookup
  • Provide basic, but extensible DataLoader implementation fixed only on a (single) MIME type.
  • Implement a LookupCoalescer for DataLoaders
  • Visual Web
  • Analyze usage patterns of NetBeans APIs / subsystems
  • Avoid duplication of implementation (eg. JSP parsing)
  • Remove binding attributes
  • Remove managed bean cross references
  • Optional application model
  • Lazy initialization
  • Delegate rendering to native browser
  • Caching of database metadata (for CachedRowset)
  • Deprecate CachedRowset and adopt JPA
  • Web & Java EE
  • Automatic redeployment of web and Java EE applications, after a change in the code. This speeds up the whole development cycle, as the user does not have to run the Ant-based deployment manually. Requires to implement background compilation, so .class files are created on the fly after Java file is saved, without going through Ant build.
  • Embed browser for viewing web applications in the IDE. This speeds up the development cycle, as the user does not need to go to a separate window to check the changes done in the code. The browser window should be refreshed automatically after each change in the code.

  • Questions and comments on the above
  • Regarding the dataloaders performance improvement, would it help to drop support for grouping more than one file in a dataobject? If we just assume one file per dataobject (and fix all usages where this is not the case), can the dataloader mechanism perform better? -- PetrJiricka
  • Well, it might allow some optimizations in the visualization layer, at least.
  • Also, it might eliminate some problems where more loaders fight for single file based on presence of another file. Such simplification can lead to speedup as well.
    • Agreed, although we will always have use cases where a given MIME type could have more than one potential owner depending on some context. Simply looking at filesystem relationships between two files is is probably not the best approach for determining the owner so we still need another convention for doing that. - MarkDey
  • Can Lookup performance be improved by simplifying the underlying implementation layers? Currently, Lookup typically delegates to InstanceDataObject, which brings in the whole DataLoader infrastructure, which internally uses MIMEResolvers... If Lookup was directly reading the underlying .instance file without using all the intermediate layers, would that improve performance? -- PetrJiricka
  • Certainly but not much. We probably have much bigger problem with .settings files and these are much harder to shortcut. If we can cut it with only (optimized) MIME resolvers involved, it would probably help too.
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