Patent Description:
In such cases, the object model can be represented at least partially in deferred form within memory. An object represented in deferred form can still be interfaced with using the interface of the object model. The caveat is that in order for the object itself to operate, the deferred form of the object would be replaced with the actual object in the object model. Thus, deferred object models allow for larger object models to be interfaced with without requiring all objects of the object model be always loaded in the memory of the computing system.

<CIT> describes a method for compact representation of extensible mark-up language (XML) documents. The method includes providing XML document data of an input XML document to a document parser. In response to document events received from the document parser during parsing of the XML document data, an intermediate representation is generated from such event. During generation of the intermediate representation components of the XML document are compressed according to a predetermined format to form a compact, intermediate representation of the XML document. The intermediate representation provides access to parsed content of the input XML document to enable a deferred document object model document.

Deferred object models are object models in which some or all of the objects within the object model are not fully represented within the object model in memory. Instead, the object is represented in deferred form. A deferred object may still be interfaced with using the interface of the object model and thus the appearance to the caller is as if the corresponding object is loaded into memory. The deferred object is used to acquire the actual object, which is then populated into the object model taking the deferred object's place prior to the object being able to function. Deferred objects take very little space in memory, as they only contain enough information to retrieve the real data when needed. Thus, deferred obj ect models make more efficient use of the memory of a computing system.

However, previously, in order to construct a deferred object model based on a hierarchical object definition, the hierarchical object definition still would conventionally be fully parsed to obtain the object definitions, and then a constructor would construct at least the deferred form of the object into the deferred object model. Since such hierarchical object definitions can be quite large, this parsing can take significant time. Thus, even though deferred object models save significant memory space, conventional deferred object models still take significant time to load into memory.

The principles described herein allow the deferred object model to be initially constructed in partial form, while still being operational. This is done using a map that correlates positions of a hierarchically structured definition and corresponding hierarchical positions within an object model. The hierarchical object definition includes object definitions that each describe a corresponding object of the object model. An object model can be constructed by parsing the hierarchical object definition, and populating the resulting objects into their proper hierarchical position within the object model (or populating the resulting deferred object into the same position within a deferred object model).

In accordance with the principles described herein, the map is accessed and used to initially construct a deferred object model that may leave some of the deferred objects unpopulated. The map is used to determine which parts of the hierarchical object definition no longer need to be parsed in order to construct this initial form of the deferred object model. Since not all of the hierarchical object definition needs to be parsed at initial construction time, the load time of the deferred object model can be significantly reduced.

If a request for an object is detected at some point after the initial construction of the deferred object model, and that requested object is not represented even in deferred form in the deferred object model, the system uses the map to find the position of the corresponding object definition in the hierarchical object definition. At that point, the system parses that position, and constructs the object. The deferred object model can then respond to the request since the object is available in memory. The object can either stay within the deferred object model, or perhaps the object can be discarded after use with a deferred form of the object remaining now within the deferred object model. Of course, similar to conventional deferred object models, if an object is requested, and that object is represented in deferred form within the deferred object model, that deferred form can be used to obtain the actual object and thus respond to the request.

Deferred object models are object models in which some or all of the objects within the object model are not fully represented within the object model in memory. Instead, the object is represented in deferred form. A deferred object may still be interfaced with using the interface of the object model and thus the appearance to the caller is as if the corresponding object is loaded into memory. The deferred object is used to acquire the actual object, which is then populated into the object model taking the deferred object's place prior to the object being able to function. Deferred objects take very little space in memory as they only contain enough information to retrieve the real data when needed. Thus, deferred obj ect models make more efficient use of the memory of a computing system.

The principles described herein allow the deferred object model to be initially constructed in partial form, while still being operational. This is done using a map that correlates positions of a hierarchically structured definition and corresponding hierarchical positions within an object model. The hierarchical object definition includes object definitions that each describe a corresponding object within the object model. An object model can be constructed by parsing the hierarchical object definition, and populating the resulting objects into their proper hierarchical position within the object model (or populating the resulting deferred object into the same position within a deferred object model).

If a request for an object is detected at some point after the initial construction of the deferred object model, and that requested object is not fully represented even in deferred form in the deferred object model, the system uses the map to find the position of the corresponding object definition in the hierarchical object definition. At that point, the system parses that position, and constructs the object. The deferred object model can then respond to the request since the object is available in memory. The object can either stay within the deferred object model, or perhaps the object can be discarded after use with a deferred form of the object remaining now within the deferred object model. Of course, similar to conventional deferred object models, if an object is requested, and that object is represented in deferred form within the deferred object model, that deferred form can be used to obtain the actual object and thus respond to the request.

Because the principles described herein are performed in the context of a computing system, some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> includes a general-purpose processor. Although not required, the processing unit <NUM> may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory <NUM> includes a physical system memory. That physical system memory may be volatile, non-volatile, or some combination of the two. In a second embodiment, the memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, the memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods (and so forth) that may be executed on the computing system. Such an executable component exists in the heap of a computing system, in computer-readable storage media, or a combination.

One of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

As used in this description and in the claims, these terms (whether expressed with or without a modifying clause) are also intended to be synonymous with the term "executable component", and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

If such acts are implemented exclusively or near-exclusively in hardware, such as within an FPGA or an ASIC, the computer-executable instructions may be hard-coded or hard-wired logic gates.

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 112A as well as input mechanisms 112B. The principles described herein are not limited to the precise output mechanisms 112A or input mechanisms 112B as such will depend on the nature of the device. However, output mechanisms 112A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 112B might include, for instance, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

Now that a computing system has been described generally with respect to <FIG>, an introduction of object models will be described with respect to <FIG> and <FIG>, and then deferred object models will be described with respect to <FIG> and <FIG>. Then, the description will proceed into the principles of the present invention with respect to <FIG> and subsequent figures.

The formulation of an object model using a hierarchical object definition will be now described with respect to <FIG>. An example of a hierarchical object definition is a JSON document. JSON documents are text documents that are stored representations of a dataset and that are conventionally parsed so that the objects described therein can be constructed into an object model in memory. However, the principles described herein are not limited to the format of the hierarchical object definition. As an example, the hierarchical object definition may be structured in text form in a markup language document, such as an extensible Markup Language (XML) document, a HyperText Markup Language (HTML) document, or any other text document. The hierarchical object definition may also be in a non-text format, such as in binary (e.g., binary JSON or any other binary format).

The object model is an in-memory representations of the dataset but is in a form that program components can interface with at runtime. As an example only, <FIG> illustrates a conventional environment <NUM> in which a hierarchical object definition <NUM> is used to construct an object model <NUM>. The hierarchical object definitions <NUM> includes multiple object definitions. Each object definition contains sufficient information for a constructor to construct an object and place the object into its proper position within the hierarchy of an object model. As an example, the hierarchical object definition <NUM> includes five object definitions <NUM> through <NUM>.

To formulate the object model, a parser first parses the object definitions from the hierarchical object definition. In <FIG>, for example, the parser <NUM> parses the object definitions <NUM> through <NUM> from the hierarchical object definition <NUM>, and provides the object definitions <NUM> through <NUM> to a constructor <NUM>. The constructor then uses the object definitions to construct corresponding objects and place those objects in their proper position within an object model. As an example, in <FIG>, the constructor <NUM> constructs object <NUM> using the corresponding object definition <NUM>, and also uses the object definition <NUM> to determine where to place the object <NUM> within an object model <NUM>. The constructor <NUM> likewise uses object definitions <NUM> through <NUM> to construct corresponding objects <NUM> through <NUM> and place those objects within the object model <NUM>.

An object model is a collection of related objects that can be interfaced with by other components in a computing system. <FIG> illustrates an example object model environment <NUM> that includes an object model <NUM> and an interface <NUM>. In this example, the object model <NUM> has five objects <NUM> through <NUM> that are hierarchically related as shown. A typical object model can have countless related objects, and so the object model <NUM> is used only for illustrative purposes and in simplified form. In this example, the interface <NUM> is shown as including six methods <NUM> through <NUM> that an external component <NUM> can perform on one, some or all of the objects in the object model <NUM>. Such an object model will be referred to as a "standard" object model as each of the objects <NUM> through <NUM> are already instantiated within the object model in memory.

A deferred object model corresponding to a standard object model can still be interfaced with using the same interface used to interface with the standard object model. However, one or more of the objects are loaded only in deferred form. That is, the deferred object can still receive an instruction to operate. However, before the instruction can proceed, the deferred form of the object is used to load the actual object into memory. Once the object performs as instructed, the object can either be kept in memory in case called upon again, or discarded to preserve memory. The deferred form of an object is much smaller than the corresponding object. Accordingly, deferred object models are helpful as they retain the appearance of the object model since the interface stays the same as it would be for a standard object model, and since the objects can still be accessed via the deferred form of the object. Accordingly, deferred object models of even large object models are more likely to fit within memory.

<FIG> and <FIG> illustrate an example environment 400A and 400B that are each the same as the environment <NUM> of <FIG>, except that a deferred object model 420A and 420B, respectively, corresponding to the standard object model <NUM> is used. Note that there is no difference in the interface <NUM> of <FIG> and <FIG> as compared to the interface <NUM> of <FIG>. Thus, the other components (e.g., external component <NUM>) need not actually operate any differently depending on whether they are using a deferred object model or a standard object model. In the convention of <FIG>, <FIG> and <FIG>, deferred objects are represented as circles having dashed-lined circumferences, whereas the corresponding actual object is represented as circles having solid-lined circumferences. Thus, in <FIG>, the objects <NUM> through <NUM> are represented with solid lines.

<FIG> shows an example environment 400A in which the deferred object model 420A includes deferred objects 421A through 425A for each of the corresponding objects <NUM> through <NUM> of the standard object model <NUM> of <FIG>. This is represented by the deferred objects 421A through 425A having dashed-lined borders. Thus, the example deferred object model 420A is a simple example in which all of the objects of the object model are represented in deferred form.

However, a deferred object model can also have a mix of deferred and standard objects. <FIG> illustrates an environment 400B in which the deferred object model 420B includes deferred objects 421B through 423B that represent deferred forms of corresponding standard objects <NUM> through <NUM> of the corresponding standard object model <NUM> of <FIG>. However, the deferred object model 420B also includes the actual objects <NUM> and <NUM> of the standard object model <NUM> of <FIG>.

In fact, the deferred object model 420B may be arrived at should an external component <NUM> have used the interface <NUM> of <FIG> to invoke objects <NUM> and <NUM>. In that case, the deferred form 424A of the object <NUM> would be used to load the object <NUM> into its proper place within the deferred object model 420B. In addition, the deferred form 425A of the object <NUM> would be used to load the object <NUM> into its proper place within the deferred object model 420B. That said, the standard objects could also be discarded allowing their deferred forms to take their place again. Thus, the population of standard objects within a deferred object model can fluctuate in order to effectively and judiciously use available memory resources.

<FIG> illustrates a flowchart of a method <NUM> for loading a deferred object model from a hierarchical object definition that defines the deferred object model, in accordance with the principles described herein. The method <NUM> includes accessing a map that correlates positions of a hierarchical object definition and corresponding hierarchical positions within an object model (act <NUM>). In addition, a partial deferred object model is initially constructed using the accessed map (act <NUM>).

In the conventional loading of object models, regardless of whether a deferred object model or a standard object model is being loaded, the hierarchical object definition that defines the object model is entirely parsed. In accordance with the principles described herein, the initial load time of the deferred object model is reduced as only some deferred objects are constructed and populated into the deferred object model upon initial construction. Thus, only some of the hierarchical object definition is parsed in order to complete the initial construction of the deferred object model. The hierarchical map correlates positions within the hierarchical object definition and hierarchical positions of the deferred object model permits this.

<FIG> also illustrate example environments 600A through 600C that show deferred object models that can be interfaced through the same user interface <NUM> as used to interface with the standard object model <NUM> of <FIG>, or the deferred object models 420A and 420B of respective <FIG> and <FIG>. Furthermore, the respective deferred object models 620A through 620C do still correspond to the standard object model <NUM> of <FIG> in this example. However, the deferred object models 620A through 620C are quite different than conventional deferred object models in that not all objects of the corresponding standard object model <NUM> are fully represented (even in deferred form) within the deferred object model.

For example, in <FIG>, the deferred object model 620A includes deferred object 621A that is a deferred form of object <NUM> and could be used to load object <NUM> into memory. In addition, the deferred object model 620A includes deferred object 622A that is a deferred form of object <NUM> and thus could be used to load object <NUM> into memory. However, there is no full representation of objects <NUM> through <NUM> (not even in deferred form) within the deferred object model 620A. Thus, as things stand in the environment 600A, the deferred object model 620A could not be used to load any of the objects <NUM>, <NUM> or <NUM> into memory.

As another example, in <FIG>, the deferred object model 620B is the same as the deferred object model 620A of <FIG>, except that the deferred object model 620B includes a deferred object 623B that is a deferred form of object <NUM>, and thus could be used to load object <NUM> into memory. However, there is still no full representation of objects <NUM> and <NUM> (even in deferred form) in the deferred object model 620B. The deferred objects 621B and 622B could be the same as the deferred objects 621A and 622A of <FIG>, and can likewise be used to load respective objects <NUM> and <NUM> into memory.

In <FIG>, the deferred object model 620C is similar to the deferred object model 620B of <FIG>, except that object <NUM> is also loaded into the deferred object model 620B, in its proper place. Thus, the deferred object model 620C includes a mix of deferred objects and standard objects, but still the deferred object model 620C lacks full representation of the object <NUM>, even in deferred form. The deferred objects 621C through 623C could be the same as the deferred objects 621B through 623B of <FIG>, and can likewise be used to load respective objects <NUM> through <NUM> into memory.

Referring back to <FIG>, the method <NUM> includes accessing a map that correlates positions of a hierarchical object definition and corresponding hierarchical positions within an object model (act <NUM>). <FIG> illustrates an example environment <NUM> that correlates positions between a hierarchical object definition <NUM> and an object model <NUM>. In this example, the hierarchical object definition <NUM> is structured the same as the hierarchical definition <NUM> of <FIG>, and also includes object definitions <NUM> through <NUM>. Also in this example, the object model <NUM> is structured the same as the object model <NUM> of <FIG>, and includes objects <NUM> through <NUM>.

The map <NUM> is illustrated as including entries <NUM> through <NUM>. Each entry correlates a position of the hierarchical object definition <NUM> and corresponding positions of the object model <NUM>. As an example, entry <NUM> correlates (as represented by bi-directional arrow <NUM>) the position <NUM> of the object definition <NUM> and corresponding position <NUM> of the object model <NUM>. Likewise, each of the bi-directional arrows <NUM> through <NUM> represent the correlation of respective entries <NUM> through <NUM> between respective positions <NUM> through <NUM> of the hierarchical object definition <NUM> and corresponding positions <NUM> through <NUM> of the object model <NUM>.

In this example, suppose that positions <NUM> through <NUM> include the position of the entirety of the corresponding object definitions <NUM> through <NUM>, and that positions <NUM> through <NUM> correspond to the entirety of the objects <NUM> through <NUM> in the object model <NUM>. Thus, the map <NUM> can include an index entry that is dedicated to a particular object and object definition. However, the positions <NUM> and <NUM> correspond to positions within the object definition <NUM>, and likewise positions <NUM> and <NUM> correspond to positions within the object <NUM> of the object model. Thus, the map <NUM> could include an index entry containing larger object definitions (e.g., for objects larger than a predetermined threshold such as <NUM> kilobytes), smaller objects such that no two entries are more than a predetermined distance apart (e.g., <NUM> kilobytes in the hierarchical object definition), or a combination thereof.

Referring back to <FIG>, the system initially constructs a deferred object model of the object model using the accessed map to parse only a subset of the plurality of object definitions included in the hierarchical object definition, thereby constructing only some deferred objects of the deferred object model (act <NUM>). As an example, the deferred object model 620A of <FIG> includes deferred objects 621A and 622A, but includes no representation at all of objects <NUM> through <NUM>.

<FIG> illustrates a flowchart of a method 800A for initially constructing the deferred object model skipping a subset of objects, in accordance with the principles described herein. The method 800A includes detecting selection of a skippable subset of the objects of the hierarchical object definition to skip construction of in deferred form in the initial construction of the deferred object model (act 801A). To construct the deferred object model 620A of <FIG>, the method 800A may have identified the skippable subset of objects as including objects <NUM>, <NUM> and <NUM>.

The method 800A further includes using the map to identify a position of the object definitions of the skippable subset of the object within the hierarchical object definition (act 802A). Referring to <FIG>, the system uses the map <NUM> (and particularly the entries <NUM> through <NUM>) to identify the positions of the object definitions <NUM>, <NUM> and <NUM> within the hierarchical object definition <NUM>. The system then skips parsing of these identified positions (act 803A), and instead parses at least a portion of the remaining positions of the hierarchical object definition (act 804A) to populate the deferred object model with a deferred form of at least some of the objects that are not in the skippable subset (act 805A). As an example, the system skips parsing of object definitions <NUM>, <NUM> and <NUM>, but parses object definitions <NUM> and <NUM>, to thereby construct the deferred object model 620A with the deferred objects 621A and 622A that represent the deferred forms of respective objects <NUM> and <NUM>.

Alternatively, or in addition, instead of identifying a skippable subset of objects to omit from the deferred object model, the system could instead affirmatively identify an includable subset of objects to include in the deferred object model. For instance, <FIG> illustrates a flowchart of a method 800B for initially constructing the deferred object model including only a subset of objects, in accordance with the principles described herein. The method 800B includes detecting selection of an includable subset of the objects of the hierarchical object definition to include in deferred form in the initial construction of the deferred object model (act 801B). To construct the deferred object model 620A of <FIG>, the method 800A may have identified the includable subset of objects as including objects <NUM> and <NUM>.

The method 800B further includes using the map to identify a position of the object definitions of the includable subset of objects within the hierarchical object definition (act 802B). Referring to <FIG>, the system uses the map <NUM> (and particularly the entries <NUM> and <NUM>) to identify the positions of the object definitions <NUM> and <NUM> within the hierarchical object definition <NUM>. The system then parses these identified positions (act 803B), and skips parsing at least a portion of the remaining positions of the hierarchical object definition (act 804B) to populate the deferred object model with a deferred form of at least some of the objects that are in the includable subset (act 805B). As an example, the system parses object definitions <NUM> and <NUM>, but skips parsing of object definitions <NUM> through <NUM>, to thereby construct the deferred object model 620A with the deferred objects 621A and 622A that represent the deferred forms of respective objects <NUM> and <NUM>.

Because the parser does not parse all of the hierarchical object definition at initial construction time, the load time of the deferred object model is significantly reduced. Later, when the deferred object model is actually used, the deferred object model may be further populated.

As an example, suppose in <FIG>, the external component <NUM> uses the interface <NUM> to instruct that an operation be performed on the object <NUM>, which is not even in deferred form in the object model 620A. The deferred object model 620A detects that an operation on the object <NUM> is requested, and then uses the map to determine a position of the corresponding object definition (e.g., object definition <NUM> in the hierarchical object definition <NUM>). The parser is then caused to parse that position thereby offering up the object definition <NUM> to the constructor, which then constructs the requested object <NUM>. Next, after the object <NUM> is used, the object could perhaps be discarded with a deferred form (e.g., deferred object 623B of <FIG>) being populated into the deferred object model. In that case, the result would be the deferred object model 620B of <FIG>.

Continuing the example, suppose in <FIG>, that the external component <NUM> then uses the interface <NUM> to instruct that an operation be performed on the object <NUM>, which is also not represented (even in deferred form) in the object model 620B. The deferred object model 620B detects that an operation on the object <NUM> is requested, and then uses the map to determine a position of the corresponding object definition (e.g., object definition <NUM> in the hierarchical object definition <NUM>). The parser is then caused to parse that position thereby offering up the object definition <NUM> to the constructor, which then constructs the requested object <NUM>. Next, after the object <NUM> is used, the object could perhaps be included within the object model. In that case, the result would be the deferred object model 620C of <FIG>.

More generally speaking, <FIG> illustrates a flowchart of a method <NUM> for further populating a deferred object model that does not include a deferred form of all of the objects described in a hierarchical object definition from which the deferred object model was constructed. Again, this further population is performed by accessing the hierarchical map (act <NUM>). Upon detecting that an object is requested that is not in deferred form in the deferred object model (act <NUM>), the map is used to determine a position of a corresponding object definition in the hierarchical object definition (act <NUM>). In response to the determination of this position, the corresponding object definition is accessed and parsed (act <NUM>). The requested object is then constructed (act <NUM>). If the object is then to be included within the object model, the constructed object is then populated into the deferred object model (act <NUM>).

An example of an entry of a hierarchical map will now be described with respect to what will be referred to herein as a "log example". In the log example, suppose that the hierarchical object definition is a JSON document that contains a log having two runs called Run A and Run B, and that each run has results, artifacts, and codeflows. Each run could be represented as an object in the object model. As an example, object <NUM> of the object model <NUM> could be a parent object called "Log", object <NUM> of object model <NUM> could represent Run A, and object <NUM> of the object model <NUM> could represent run B. Each run could have an entry within the map that tells where in the JSON document each run is positioned. In an example, the entry could thus read as follows for the particular run called "Run A":
Run A
Hierarchical Position: Log\RunA.

This map entry tells where Run A is located within the JSON document. Thus, to construct Run A in the object model whether in actual form or deferred form, the parser would parse <NUM>,<NUM> bytes beginning at byte address <NUM>,<NUM> to obtain the Run A object definition. The constructor would take the parsed Run A object definition and build the Run A object or the Run A deferred object. Alternatively, to skip construction of Run A, the parser can skip parsing beginning from byte address <NUM>,<NUM> for the next <NUM>,<NUM> bytes.

In one embodiment, the object could be a collection of indexed elements, such as an array. In this case, the correlated positions could be expressed for the indexed elements (e.g., for the array elements themselves). For instance, in the log example, Run A (e.g., object <NUM>) could contain a child array (e.g., object <NUM>) called Results that could be an index having a large number of elements. The following is an example representation of an entry for the Results array within the map.

In the above example, the positions for each element are provided within the ElementStarts array. The first element of the ElementStarts array gives the byte address for the first element. The remaining elements of the ElementStarts array gives the relative byte offset. From this information, the system can determine that Results[<NUM>] begins at byte address <NUM> and is <NUM> bytes long, Results[<NUM>] begins at byte address <NUM>,<NUM> (i.e., <NUM>,<NUM>+<NUM>) and is <NUM> bytes long, and so forth. Thus, if Result[<NUM>] is identified as an object to be populated (whether in actual or deferred form) within a deferred object model, the system would parse <NUM> bytes from byte address <NUM>,<NUM> in the JSON document, provide the Results[<NUM>] object definition to the constructor, whereupon Results[<NUM>] would be constructed and populated into the deferred object model.

The count is helpful as it allows the results to be rendered appropriately on screen. For instance, the scroll bar can be rendered properly given the position of the array elements being displayed. As an example, if results from Results[<NUM>] to Results[<NUM>] are displayed, then a proper scroll bar can be displayed showing the user that they are displaying a position about halfway through the array, and displaying about <NUM> percent of the array results. This is true even if far less than all of the Results array elements are within the object model.

In one embodiment, the ElementStarts positions can be provided not for every indexed element - but at regular indices of the collection (e.g., every <NUM> elements). The following is an example that would enable this.

Here, the entry further identifies the index interval (i.e., every five elements). Thus, to get to Results[<NUM>], the system would find the closest prior indexed element for which there is a start address determinable from the entry. Here, the start address for Results [<NUM>] would again be byte address <NUM>,<NUM>, and the start address for Results[<NUM>] would be <NUM> bytes after that, or byte address <NUM>,<NUM>. The system could then parse from this point until the object description for Results[<NUM>] is encountered and fully parsed. Thus, the Results[<NUM>] object description could be provided to the constructor, to construct Results[<NUM>] and populate Results[<NUM>] into the object model. This embodiment requires a little more parsing, but also lets the map be smaller.

Accordingly, a hierarchical map has been described that allows for a deferred object model to be initially constructed in only partial form, with additional just-in-time parsing performed as objects are needed. Thus, the principles described herein allow for faster load times, while still providing the appearance after that initial load that the entire object model has always been available. The hierarchical map may also be used for other purposes, as it may contain sufficient information to respond to some types of queries. As an example, if there is a query for the number of results for all runs, this can be quickly determined using only the hierarchical map, without the need to perform analysis on the object model itself. Thus, the hierarchical map has a number of uses.

Claim 1:
A method (<NUM>), performed by a computing system (<NUM>), for loading a deferred object model (620A, 620B, 620C) into a memory (<NUM>) of the computing system without initially loading an entirety of the deferred object model (<NUM>) into the memory and without having to fully parse a hierarchical object definition (<NUM>) that defines the deferred object model, the method comprising:
accessing (<NUM>) a map (<NUM>) that correlates (<NUM>-<NUM>) positions (<NUM>-<NUM>) of a hierarchical object definition (<NUM>) and corresponding hierarchical positions (<NUM>-<NUM>) within an object model (<NUM>), wherein the hierarchical object definition includes a plurality of object definitions (<NUM>-<NUM>) that each describe a corresponding object (<NUM>-<NUM>) and a hierarchical position of the corresponding object within the object model such that a plurality of objects are included in the object model,
each object in the plurality of objects has a corresponding entry in the map (<NUM>), and a first object in the plurality of objects comprising an array of indexed elements represented by a first entry in the map,
the first entry includes position data for not every indexed element in the array, wherein the indexed elements are at a regular index of elements, and
positions of entries in the map (<NUM>) are controlled so that positions of any two of the entries for smaller objects that are not larger than a predetermined threshold, are no more than a predetermined distance apart; and
initially constructing (<NUM>) the deferred object model of the object model using the map to parse only a subset of the plurality of object definitions included in the hierarchical object definition, thereby constructing only some deferred objects of the deferred object model, thereby reducing load time of the deferred object model as compared to completely loading the deferred object model into the memory.