Issie
GatherData Type
Scaffolding for building a FastSimulation, and alive only while one is built. It used to be four `Map`s: the flattened design indexed the several ways the phases after the flatten needed it, all of them keyed structurally by (ComponentId, access path). Every one of those keys cost a boxed comparison per tree level of every lookup, and the build does millions of lookups - a measured fifth of a 480,000-component build went on one of them. They are now a single index space instead: the flatten creates each FastComponent, stamps it with its position in `Comps`, and expresses every link it finds as those indices. Nothing here is keyed by anything but an int, and what a built simulation offers the rest of the program - the store in gather order, and one map from a design-time name into it - is made once at the end, from this. One store and one index space, holding the FastComponents themselves: custom against ordinary is a PREDICATE over it, never a second store. Splitting them is the obvious tidy-up and it is what would break this - the indices the links carry would then mean two different things. Deliberately not kept after the build. It holds a SimulationComponent per component INSTANCE through the FastComponents it stores, so on a large design it is one of the biggest things the simulator ever allocates, and a FastSimulation left holding one made every later edit slower by giving each major GC all of it to trace.
Record fields
| Record Field | Description |
|
|
Full Usage:
Labels
Field type: string array
Modifiers: mutable |
Shortcut to find the label of a component, indexed by the component's DESIGN id. An array and not a map because design ComponentIds are allocated densely from 1 (ComponentId), and getFullSimName below does one lookup per element of the access path for every component of the expanded design - millions of them on a design that expands, each one a boxed comparison per tree level as a Map. An id the design does not have reads as "*", which is what the Map gave for a key it did not hold. Notice that the access path is not needed here because labels of the graph inside a custom component are identical for different instances of the component. Mutable because the flatten grows it as it meets ids: the largest design ComponentId is not known until the whole design has been walked, and walking it twice to find out would cost more than the growth does.
|
Instance members
| Instance member | Description |
|
|
|