Stub Indexes For a stub element, a number of keys for different indexes can be provided PSI elements can then be retrieved by such keys Sample indexes: Classes by name (Goto Class) Symbols by name (Goto Symbol) Classes by superclass name (Goto Implementations) īackground Analysis Multiple passes with different priorities Faster analysis performed first Separate high-priority passes for highlighting only visible area Minimum affected scope is re-analyzed after change Cancellation on user activity Cancellation flag checked in many low-level operations, exception thrown and caught on top level PSI Stubs Compact binary serialization of externally visible interface of file Can be provided for any language Must be sufficient for resolving imported declarations without parsing imported files PSI elements can exist in two modes: stub-based and AST-based Switching from stubs to AST is transparent for the client Updating PSI Syntax highlighting based on lexer Synchronous and incremental PSI updates triggered by background analysis Starts after 300 ms of inactivity Cancelled by next user action Syntax tree (AST) is built for entire file PSI is replaced for changed parts of AST PSI Program Source Interface Read/write access to program syntax tree From directories down to individual tokens Works across languages Some elements (whitespace, comment etc.) used by all languages īuilding PSI from Source Lexer produces stream of tokens Lexers usually generated with Flex Parser builds syntax tree Usually hand-written recursive descent Table-driven parsers seldom provide adequate error recovery Language creates PSI elements for syntax tree nodes Indexing Framework Usages Word index Key: hashcode of word Value: occurrence mask identifier, comment, string literal Used for Find in Path, Find Usages etc. Indexing Framework Indexer builds list of key/value pairs from file content Keys and values are arbitrary beans Indexer provides binary serialization for keys and values Application-level same file under different projects indexed only once
INTELLIJ APPCODE UPDATE
Persistent File System Complete snapshot of files under project stored in single file Improves startup performance Directory tree walk is very expensive, especially on Windows Provides old content when file is changed Required for update of indexes Supports custom persistent attributes įile System Synchronization On startup, background synchronization of all files under project is performed Watching for file system notifications ReadDirector圜hangesW() on Windows /dev/fsevents on Mac (fslogger) Linux has no API for recursive watching, requires keeping a file handle for every directory under project Services: Lazy Loading No strict lifecycle: loaded on demand Key for loading service is FQN of service interface Not even classloading happens before service is accessed Service may have persistent settings which are automatically loaded on instantiation ĭisposer Hierarchy Tree of dependencies between objects Disposing of parent object also disposes of all its children Relationships stored outside of object: no common base class required Typical actions on dispose: Detaching listeners Stopping timers/background threads UI component cleanup
INTELLIJ APPCODE REGISTRATION
Learn about performance optimization techniques used in IntelliJ IDEA Understand the factors affecting IntelliJ IDEA performance in normal use Īgenda Elements of Architecture Performance Tips Ĭomponent Model Hierarchy of PicoContainer containers 3 levels of components: application, project and module Components have strictly defined lifecycle Registration through XML configuration files (typically) IntelliJ IDEA Architecture and Performance Dmit ry Jemerov Development Lead JetBrains, Inc.
IntelliJ IDEA Architecture and Performance
0 kommentar(er)
