The core of Xic is the main database, which stores objects in a format that can be rapidly accessed spatially. The database, when given a rectangular region, will efficiently provide a list of contained objects whose bounding boxes overlap the given region. For example, when the user clicks or drags in a drawing window, the main database will quickly provide a list of the objects which overlap this area, so they may be shown as selected.
Each cell in memory has a database for each layer used by objects in the cell, plus a database corresponding to a dummy layer which contains the locations of subcell instances. The cells themselves are saved in one or more hash tables, the ``symbol tables''. The symbol tables allow cell data to be rapidly found by name. Cell name strings are saved in a common string table, so that address values can be used for efficient string comparison.
Each symbol table represents a self-contained design space, which can be rapidly switched between. Xic allows the user to define any number of symbol tables. Cells of the same name can not be saved in the same symbol table, but can exist in different symbol tables. Thus, for example, different versions of the same cell hierarchy can be kept in memory simultaneously, but the user can only view/edit using one symbol table at a time. This capability is used transparently by the geometry comparison functions, for example, in comparing two versions of the same cell.
The main database is organized as a tree, though the details are proprietary. This structure is self-balancing, unlike KD trees, thus there is no need to ``rebuild'' the database when objects are added or removed. The structure is optimized for rapid access, at a cost of time to build the structure. It is also optimized for low memory consumption, at a slight cost in speed.
When a file in loaded into the Xic ``main'' database, cell structures are created for each cell defined in the file. The cell structures contain trees for each layer used plus one for subcells if any, and are linked into the current symbol table.
The main database, with spatial access features, is not particularly efficient with regard to memory use. Large designs may not fit into available memory, depending on the machine. The physical memory limitation of the computer determines the maximum size of a file that can be read into Xic efficiently. Very roughly, the memory available should equal the size of the (uncompressed) GDSII file. If the file requires too much memory, Xic performance can become very sluggish due to page swapping, or in some cases the operating system will halt the process if memory limits are exceeded.
Although the design must reside in the main database for efficient cell editing, there are operations where this is not needed. There are provisions for handling extremely large files which can not be normally loaded.