NZ616299B - System and method for batch evaluation programs - Google Patents
System and method for batch evaluation programsInfo
- Publication number
- NZ616299B NZ616299B NZ616299A NZ61629913A NZ616299B NZ 616299 B NZ616299 B NZ 616299B NZ 616299 A NZ616299 A NZ 616299A NZ 61629913 A NZ61629913 A NZ 61629913A NZ 616299 B NZ616299 B NZ 616299B
- Authority
- NZ
- New Zealand
- Prior art keywords
- expression
- frame
- call
- child frame
- processing
- Prior art date
Links
- 238000011156 evaluation Methods 0.000 title claims description 29
- 230000014509 gene expression Effects 0.000 claims abstract description 136
- 230000004048 modification Effects 0.000 claims abstract description 9
- 238000006011 modification reaction Methods 0.000 claims abstract description 9
- 238000000034 method Methods 0.000 claims abstract description 6
- 238000007689 inspection Methods 0.000 claims description 18
- 230000000903 blocking Effects 0.000 description 12
- 238000005192 partition Methods 0.000 description 11
- 230000000875 corresponding Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000002104 routine Effects 0.000 description 3
- 239000004065 semiconductor Substances 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/541—Client-server
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Abstract
computer-implemented method and a computer system for evaluating a program instruction within the stack evaluator (118) are disclosed. The computer system comprises a memory; and a processor. The processor is configured to generate a call frame associated with the program instruction within a call stack (202) with the call frame includes a first expression specified by the program instruction; generate a child frame associated with the first expression within the call stack (202), determines whether the first expression associated with the child frame should be sent for processing by an application server. In response to processing the first expression associated with the child frame, receive a modification to the child frame that sets the value of the first expression within the child frame, and process the call frame based at least in part on the value of the first expression within the child frame. The processor is further configured to determine that that the processing of the child frame has been blocked and when the processing of the child frame has been blocked, the first expression is batch processed by an application server with one or more other expressions. ll stack (202) with the call frame includes a first expression specified by the program instruction; generate a child frame associated with the first expression within the call stack (202), determines whether the first expression associated with the child frame should be sent for processing by an application server. In response to processing the first expression associated with the child frame, receive a modification to the child frame that sets the value of the first expression within the child frame, and process the call frame based at least in part on the value of the first expression within the child frame. The processor is further configured to determine that that the processing of the child frame has been blocked and when the processing of the child frame has been blocked, the first expression is batch processed by an application server with one or more other expressions.
Description
SYSTEM AND METHOD FOR BATCH EVALUATION PROGRAMS
Technical Field
The present disclosure relates generally to data access and analysis
and, more specifically, to a system and method for evaluating programs in
batch.
Background
Software applications, such as financial analysis applications, allow
users to create and interact with large software data objects. Such data objects
organize data relevant to the software application and provide methods that
allow operations to be performed on the data. In some situations, the
operations are performed on a large set of data and require high processing
power as well as high bandwidth access to a database.
Typically, for the efficient processing of such operations, the bulk of
the processing occurs on a server that is external to the computing device that
executes the software application. In operation, the software application
transmits calls associated with the operations to be performed on the data, and
the calls are processed on the server. The results of the processing are then
transmitted back to the software application for presentation to the user.
One drawback to such an implementation is that the server receives
and processes one call per operation to be performed. In situations where
operations are performed on an extremely large set of data, serving a large
amount of calls can slow down the server and, in some cases, crash the server.
Such a scenario is extremely undesirable because the server is extremely slow
and in some cases entirely unusable, thereby affecting the overall user
experience.
As the foregoing illustrates, what is needed in the art is a mechanism
for efficiently managing and processing a large volume of calls to be processed
on a server.
Summary
One aspect of the present disclosure provides a computer-
implemented method for evaluating a program instruction within the stack
evaluator. The method includes the steps of generating a call frame associated
with the program instruction within a call stack, wherein the call frame includes a
first expression specified by the program instruction, generating a child frame
associated with the first expression within the call stack, receiving a modification
to the child frame that sets the value of the first expression within the child
frame, and processing the call frame based at least in part on the value of the
first expression within the child frame.
Advantageously, because a single batch processing request is
transmitted to the application server for a group of similar expressions, the
number of processing requests received by the application server is reduced.
As a result, the application server is not burdened with a large amount of
requests at any given time. Therefore, the overall processing efficiency of the
application server is increased and the overall processing latency of the
application server is reduced.
Brief Description of the Figures
So that the manner in which the above recited features of the present
invention can be understood in detail, a more particular description of the
invention, briefly summarized above, may be had by reference to embodiments,
some of which are illustrated in the appended drawings. It is to be noted,
however, that the appended drawings illustrate only typical embodiments of this
invention and are therefore not to be considered limiting of its scope, for the
invention may admit to other equally effective embodiments.
Figure 1 illustrates a system that enables an application to be
processed in batch-mode, according to one embodiment of the invention;
Figure 2A illustrates a more detailed view of the stack evaluator of
Figure 1, according to one embodiment of the invention;
Figure 2B illustrates a more detailed view of the stack of Figure 2A,
according to one embodiment of the invention;
Figure 3 illustrates a more detailed view of the batching module of
Figure 1, according to one embodiment of the invention;
Figure 4 is an exemplary system within which the application of
Figure 1 could execute, according to one embodiment of the invention;
Figures 5A and 5B set forth a flow diagram of method steps for
evaluating a program instruction within the stack evaluator, according to one
embodiment of the invention; and
Figures 6A and 6B set forth a flow diagram of method steps for
processing related program instructions in batches, according to one
embodiment of the invention.
Detailed Description
Figure 1 illustrates a system 100 that enables an application to be
processed in batch-mode. As shown, the system 100 includes a application
102, service logic 104, an application server 106 and a data store 108.
The application 102 is a software program that allows a user to
create, analyze and interact with workflows having one or more documents. A
document is typically composed of several data objects, each having a
particular type and function. The data objects that could make up a document
are described in greater detail below. A user, via a programming interface, can
typically write program routines that interact with the data objects to generate
the results or analysis needed. Again, some examples of such instructions are
described below.
The service logic 104 is an infrastructure layer that, among other
things, allows the application 102 to communicate with the application server
106. In one embodiment, the service logic 104 includes a messaging service
(not shown) that allows the application 102 and the application server 106 to
communicate asynchronously via messages. The service logic 104 includes a
stack evaluator 118 and a batching module 120. The stack evaluator 118 is an
infrastructure module that manages the stack-based evaluation of program
routines associated with the application 102. Each program routine is
associated with a call stack that includes multiple frames, each frame storing
information about a particular portion of the program routine. The batching
module 120 allows for the batch processing on the application server 106 of
program routines being evaluated within the stack evaluator 118. The functions
of the stack evaluator 118 and the batching module 120 is described in greater
detail below in conjunction with Figures 2A-6B.
The application server 106 includes logical elements such as input
receiving logic 110, an object model 112, evaluation logic 114 and data store
access logic 116. The application server 106 may be implemented as a
special-purpose computer system having the logical elements shown in Figure
1. In one embodiment, the logical elements comprise program instructions
stored on one or more machine-readable storage media. Alternatively, the
logical elements may be implemented in hardware, firmware, or a combination
thereof.
The input receiving logic 110 receives inputs from different
applications executing within the system 100, such as the application 102, via
the service logic 104. Inputs include, but are not limited to, processing
requests, data access/storage requests and expression evaluation requests.
The input receiving logic 110 transmits requests received from the different
applications to logical elements within the application server 106 that are
configured to process those requests.
The object model 112 is a model that specifies a universe of data
objects, relationships between the data objects, higher-order data objects
generated based on one or more zero-order data objects in the universe,
higher-order data objects generated based on other higher-order data objects,
and auxiliary entities related to the universe of data objects. The data objects
may be created by users via data object creation mechanisms exposed in
different applications, such as the application 102. In one embodiment, the
object model 112 includes only references to the data objects and data related
to those data objects is stored within the data store 108. Persons skilled in the
art would understand that any other data objects can be included in the object
model 112.
The evaluation logic 114 receives expression evaluation requests
from applications, such as the application 102, via the input receiving logic and
evaluates the expressions specified in those requests. An expression typically
includes a reference to one or more data objects included in the object model
112 and specifies one or more operations to be performed on those data
objects. The evaluation logic 114, when processing a particular expression,
may create, modify, delete and store data objects that are associated with the
universe of data objects included in the object model 112. In addition, the
evaluation logic 112 transmits the results of processing the particular
expression to the application that transmitted the expression evaluation request.
In an embodiment, application server 106 comprises data store
access logic 116. Data store access logic 116 may comprise a set of program
instructions which, when executed by one or more processors, are operable to
access and retrieve data from data store 108. For example, data store access
logic 116 may be a database client or an Open Database Connectivity (ODBC)
client that supports calls to a database server that manages data store 108.
Data store 108 may be any type of structured storage for storing data including,
but not limited to, relational or object-oriented databases, data warehouses,
directories, data files, and any other structured data storage.
Figure 2A illustrates a more detailed view of the stack evaluator 118
of Figure 1, according to one embodiment of the invention. As shown, the stack
evaluator 118 includes multiple stacks 202.
The stack evaluator 118 generates a stack 202 corresponding to
each program subroutine (referred to herein as a “subroutine”) associated with
the application 102. Typically, a subroutine includes multiple instructions,
where each instruction includes one or more expressions to be evaluated. As
discussed above, an expression may include an argument, a parameter and/or
a metric, as described above. When evaluating a particular instruction, the
stack evaluator 118 generates a different frame for each expression within that
instruction. For example, an array frame is generated for each argument of an
instruction and a call frame is generated for performing a specified operation on
the arguments that were evaluated in the array frame(s).
Figure 2B illustrates a more detailed view of a stack 202 of Figure 2A,
according to one embodiment of the invention. As shown, the stack 202
includes a frames portion 206, a value portion 208 and an expression portion
210.
The frames portion 206 includes multiple frames 204, where each
frame 204 corresponds to a particular evaluation iteration of the subroutine
corresponding to the stack 202. When a particular frame is ready for
evaluation, the stack 202 transitions to an “evaluation state.” During evaluation,
the expressions within the current frame are first extracted and pushed into the
expression array 210, such as exp 214. The value of the expressions are then
evaluated and pushed into the value array 208. If an expression being
evaluated is nested, the evaluation of the expression in the current frame 204
generates one or more new frames 204 that are evaluated before evaluating the
current frame. Once the evaluation of each frame in the stack 202 is
completed, the stack 202 transitions to a “completed state.”
Figure 3 illustrates a more detailed view of the batching module 120
of Figure 1, according to one embodiment of the invention. As shown, the
batching module 120 includes an inspection engine 302, a blocking engine 304
and an unblocking engine.
The batching module 120 monitors the execution of program
subroutines within the stack evaluator 118 to identify program subroutines that
can be processed within the application server 106 in batch. More specifically,
for each stack 202, the inspection engine 302 analyzes a current expression
within a frame 204 of the stack 202 to determine whether the evaluation of the
expression should be evaluated in batch with other similar expressions.
To determine whether a particular expression should be evaluated in
batch with other similar expressions, the inspection engine 302 first determines
the type of the expression. An expression may be an economic index, an
instrument, a metric, an input object, an output object, a parameter, a time
series, a higher-order-object, or any higher-order object in the object model.
Based on the type of expression, the inspection engine 302 then determines
whether the type of the expression falls within a pre-determined category of
expressions that should be processed in batch with other expressions of the
same type or a similar type. For example, an expression that includes a metric
for which the evaluation involves a database access or a model access should
be processed in batch with other expressions that include metrics for which the
evaluation involves database accesses or model accesses.
As another example, consider the following program instruction:
return this.close + this.open, where “this” refers to a time series. There are
multiple expressions within the program instruction, such as “this.close,” “+,”
and “this.open.” In one scenario, the program instruction may be evaluated
multiple times, each evaluation generating a different stack 202. In such a
scenario, the inspection engine 302 may identify the expressions “this.close”
and “this.open” as expressions that should be evaluated in batch with similar
expressions. Therefore, for each stack 202, the corresponding “this.close”
expression is evaluated in batch with the “this.close” expressions in the
remaining stacks 202. Similarly, for each stack 202, the corresponding
“this.open” expression is evaluated in batch with the “this.open” expressions in
the remaining stacks 202.
For a particular stack 202, once the inspection engine 302 determines
that the current expression should be evaluated in batch with other similar
expressions, the blocking engine 304 blocks the processing of the current
expression and the stack 202, in general. At this instant, the stack 202
transitions to a “blocked state.” Therefore, at any given point, a stack 202 is
either in an evaluation state, a blocked state or a completed state. When all the
stacks 202 are either in a blocked state or a completed state, the blocking
engine 304 prepares the current expressions in each of the blocked stacks 202
(referred to herein as the “blocked expressions”) for evaluation on the
application server 106 in batch. The blocking engine 304 divides the blocked
expressions into partitions, where blocked expressions in a particular partition
are each associated with at least one similar characteristic. For example, each
blocked expression in a particular partition may need a database call to be
executed by the application server 106.
Once the blocked expressions are divided into partitions, the blocking
engine 304 dispatches, per partition, a single call to the application server 106
for evaluating all of the expressions in that partition. The application server 106
evaluates the expression in a manner described above in conjunction with
Figure 1. The application server 106 transmits the results associated with each
expression in a partition to the unblocking engine 306. For each result
associated with a particular expression, the unblocking engine 306 updates the
stack 202 corresponding to the expression to store the result. The updated
stack 202 is then unblocked and the frames 204 within the stack 202 continue
to be processed.
The inspection engine 302 continues to inspect the stacks 202 to
identify expressions that can be evaluated in batch. In turn, the blocking engine
304 continues to block stacks 202 and dispatch calls for evaluating similar
expressions in batch until each of the stacks 202 is in a completed state. In
such a manner, similar expressions from different stacks 202 are processed in
batch within the application server 106, thus increasing the efficiency of the
overall system.
Figure 4 is an exemplary system within which the application 102 of
Figure 1 could execute, according to one embodiment of the invention. As
shown, the system 400 includes a system memory 402, an external memory
404, a central processing unit (CPU) 406, an input device 410 and an display
device 412.
The system memory 402 includes the application 102 previously
described herein. The system memory 402 is a memory space, usually a
random access memory (RAM), that temporarily stores software programs
running within the system 400 at any given time. The CPU 406 executes a
sequence of stored instructions associated with and/or transmitted from the
various elements in the computer system 400. The external memory 404 is a
storage device, e.g. a hard disk, for storing data associated with the application
102. The input device 410 is an end-user controlled input device, e.g. a mouse
or keyboard, that allows a user to manipulate various aspects of the application
102. The display device 412 may be a cathode-ray tube (CRT), a liquid crystal
display (LCD) or any other type of display device.
Figures 5A and 5B set forth a flow diagram of method steps for
evaluating a program instruction within the stack evaluator, according to one
embodiment of the invention. Although the method steps are described in
conjunction with the system for Figure 1-4, persons skilled in the art will
understand that any system configured to perform the method steps, in any
order, is within the scope of the invention.
The method 500 begins at step 501, where the stack evaluator 118
generates a stack 202 corresponding to a program subroutine associated with
the application 102 that is being evaluated. At step 502, the stack evaluator
118 generates a call frame associated with a particular program instruction
included in the program subroutine. As discussed above, each program
instruction within a program subroutine includes one or more expressions to be
evaluated. An expression may be an argument, a parameter and/or a metric,
as described above. Therefore, the call frame associated with the particular
program instruction includes the one or more expressions to be evaluated.
At step 504, the stack evaluator 118 generates a different child frame
for evaluating each expression within that instruction. For example, an array
frame is generated for each argument of an instruction. At step 506, the stack
evaluator 118 transitions the stack 202 to an evaluation state. At step 508, the
stack evaluator 118 begins the evaluation of an expression included in a next
child frame to be evaluated (referred to herein as the “current frame”). An
expression is evaluated either within the stack evaluator 118 itself or needs to
be processed within the application server 106 as described above in
conjunction with Figure 1.
At step 510, the stack evaluator 118 receives a request from the
inspection engine 302 to inspect the current frame. As described above, each
time a new frame is being evaluated, the inspection engine analyzes a current
expression that is to be evaluated within the frame to determine whether the
evaluation of the expression should be executed in batch with other similar
expressions. The process of inspection and batch execution is described in
detail with respect to Figures 6A and 6B.
At step 512, the stack evaluator 118 determines whether the stack
202 is in a blocked state. As discussed above and described in greater detail
with respect to Figures 6A and 6B, for a particular stack 202, if the inspection
engine 302 determines that the current expression should be evaluated in batch
with other similar expressions, then the blocking engine 304 blocks the
processing of the current expression and the stack 202, in general. If, at step
512, the stack evaluator 118 determines that the stack 202 is in a blocked state,
then the method 500 proceeds to step 514, where the stack evaluator 118 waits
until the stack 202 is unblocked by the unblocking engine 306. However, if, at
step 512, the stack evaluator 118 determines that the stack 202 is not in a
blocked state, then the method 500 proceeds to step 516, where the stack
evaluator 118 completes the evaluation of the expression in the current frame.
At step 518, the stack evaluator 118 determines whether any child
frames were generated at step 504 are still not evaluated. If so, then the
method proceeds to step 508 previously described herein. If the stack
evaluator 118 determines that all the child frames were generated at step 504
have been evaluated, then the method 500 proceeds to step 520. At step 520,
the stack evaluator 118 determines whether the call frame that was generated
at step 502 has been evaluated.
If, at step 520, the stack evaluator 118 determines that the call frame
that was generated at step 502 has not been evaluated, then the method 500
proceeds to step 522. At step 522, the stack evaluator 118 begins the
evaluation of the call frame based on the expressions that were evaluated via
the child frames. The method then proceeds to step 510 previously described
herein.
If, however, at step 520, the stack evaluator 118 determines that the
call frame that was generated at step 502 has already been evaluated, then the
method 500 proceeds to step 524. At step 524, the stack evaluator 118
transitions the state of the the stack 202 to the completed state. The method
500 then ends.
As discussed above, the application 102 is associated with one or
more program subroutines and each program subroutine includes multiple
program instructions. Persons skilled in the art would recognize that the stack
evaluator 118 executes the method steps described with respect to Figures 5A
and 5B for each program instruction included in each program subroutine
associated with the application 102, as discussed above.
Figures 6A and 6B set forth a flow diagram of method steps for
processing related program instructions in batches, according to one
embodiment of the invention. Although the method steps are described in
conjunction with the system for Figure 1-4, persons skilled in the art will
understand that any system configured to perform the method steps, in any
order, is within the scope of the invention.
The method 600 begins at step 602, where the inspection engine
302, for each stack 202, inspects an expression within the stack 202 that is to
be evaluated. At step 604, the inspection engine 302, based on the inspection,
identifies one or more expressions included in the unblocked stacks that should
be batch processed. As previously described, the inspections engine 302
identifies such expressions based on a type of the expression, the number of
inputs specified in the expression, the type of operation to be performed, etc.
At step 606, the blocking engine 304 blocks the processing of the
expressions identified at step 604 and the stacks 202 that include those
expressions. In one embodiment, the blocking engine 304 transitions the state
of each of the stacks 202 to a blocked state. At step 606, the blocking engine
304 determines whether all the stacks are in a blocked or completed state. If, at
step 606, at least one stack is not in a blocked or completed state, then the
method 600 returns to step 602. If, however, at step 606, all the stacks are in a
blocked or completed state, then the method 600 proceeds to step 610.
At step 610, the blocking engine 304 divides the expressions included
in the blocked stacks into partitions, where expressions in a particular partition
are each associated with at least one similar characteristic. For example, each
blocked expression in a particular partition may be a database call to be
executed by the application server 106. At step 612, once the blocked
expressions are divided into partitions, the blocking engine 304 dispatches, for
each partition, a single call to the application server 106 for evaluating each of
the expressions in that partition in batch. The application server 106 evaluates
the expression in a manner described above in conjunction with Figure 1.
At step 614, the unblocking engine 306 receives, for each partition,
the results for each expression in the partition. At step 616, for each received
result, the unblocking engine 306 updates the stack 202 corresponding to the
expression for which the result was generated to store the result. At step 618,
the unblocking engine 306 unblocks each of the updated stacks 202, which then
continue to be processed.
Advantageously, because a single batch processing request is
transmitted to the application server for a group of similar expressions, the
number of processing requests received by the application server is reduced.
As a result, the application server is not burdened with a large amount of
requests at any given time. Therefore, the overall processing efficiency of the
application server is increased and the overall processing latency of the
application server is reduced.
One embodiment of the invention may be implemented as a program
product for use with a computer system. The program(s) of the program
product define functions of the embodiments (including the methods described
herein) and can be contained on a variety of computer-readable storage media.
Illustrative computer-readable storage media include, but are not limited to: (i)
non-writable storage media (e.g., read-only memory devices within a computer
such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM
chips or any type of solid-state non-volatile semiconductor memory) on which
information is permanently stored; and (ii) writable storage media (e.g., floppy
disks within a diskette drive or hard-disk drive or any type of solid-state random-
access semiconductor memory) on which alterable information is stored.
Another embodiment of the invention may be implemented as a
program product deployed for use over a network. In such an embodiment, the
program product may be accessed via a web browser.
The invention has been described above with reference to specific
embodiments. Persons skilled in the art, however, will understand that various
modifications and changes may be made thereto without departing from the
broader spirit and scope of the invention as set forth in the appended claims.
The foregoing description and drawings are, accordingly, to be regarded in an
illustrative rather than a restrictive sense.
Claims (20)
1. A computer-implemented method for evaluating a program instruction within a stack evaluator, the method comprising: generating a call frame associated with the program instruction within a call stack, wherein the call frame includes a first expression specified by the program instruction; generating a child frame associated with the first expression within the call stack; determining whether the first expression associated with the child frame should be sent for processing by an application server; in response to processing the first expression associated with the child frame, receiving a modification to the child frame that sets a value of the first expression within the child frame; and processing the call frame based at least in part on the value of the first expression within the child frame.
2. The method of claim 1, further comprising, after generating the child frame associated with the first expression, transitioning the call stack to a stack evaluation state.
3. The method of claim 2, further comprising determining that the processing of the child frame has been blocked.
4. The method of claim 3, wherein determining that the processing of the child frame has been blocked comprises determining that the call stack has transitioned to a blocked state.
5. The method of claim 3, wherein, when the processing of the child frame has been blocked, the first expression is batch processed by the application server with one or more other expressions.
6. The method of claim 3, further comprising waiting for the processing of the child frame to be unblocked before processing the call frame.
7. The method of claim 1, further comprising generating a second call frame associated with the program instruction within the call stack, wherein the call frame includes a second expression specified by the program instruction, and generating a child frame associated with the second expression within the call stack.
8. The method of claim 7, wherein processing the first expression includes the execution of a database call.
9. The method of claim 1, further comprising receiving a request from a software module to inspect the child frame, wherein the software module applies the modification to the child frame in response to the inspection of the child frame.
10. The method of claim 9, wherein the inspection of the child frame comprises analyzing one or more characteristics associated with the first expression.
11. A computer readable medium storing instructions that, when executed by a processor, cause the processor to evaluate a program instruction within a stack evaluator, by performing the steps of: generating a call frame associated with the program instruction within a call stack, wherein the call frame includes a first expression specified by the program instruction; generating a child frame associated with the first expression within the call stack; determining whether the first expression associated with the child frame should be sent for processing by an application server; in response to processing the first expression associated with the child frame, receiving a modification to the child frame that sets a value of the first expression within the child frame; and processing the call frame based at least in part on the value of the first expression within the child frame.
12. The computer readable medium of claim 11, further comprising, after generating the child frame associated with the first expression, transitioning the call stack to a stack evaluation state.
13. The computer readable medium of claim 12, further comprising determining that the processing of the child frame has been blocked.
14. The computer readable medium of claim 13, wherein determining that the processing of the child frame has been blocked comprises determining that the call stack has transitioned to a blocked state.
15. The computer readable medium of claim 13, wherein, when the processing of the child frame has been blocked, the first expression is batch processed by the application server with one or more other expressions.
16. The computer readable medium of claim 13, further comprising waiting for the processing of the child frame to be unblocked before processing the call frame.
17. The computer readable medium of claim 11, further comprising generating a second call frame associated with the program instruction within the call stack, wherein the call frame includes a second expression specified by the program instruction, and generating a child frame associated with the second expression within the call stack.
18. The computer readable medium of claim 11, further comprising receiving a request from a software module to inspect the child frame, wherein the software module applies the modification to the child frame in response to the inspection of the child frame.
19. The computer readable medium of claim 18, wherein the inspection of the child frame comprises analyzing one or more characteristics associated with the first expression.
20. A computer system, comprising: a memory; and a processor configured to: generate a call frame associated with the program instruction within a call stack, wherein the call frame includes a first expression specified by the program instruction, generate a child frame associated with the first expression within the call stack, determine whether the first expression associated with the child frame should be sent for processing by an application server, in response to processing the first expression associated with the child frame, receive a modification to the child frame that sets a value of the first expression within the child frame, and process the call frame based at least in part on the value of the first expression within the child frame. Palantir Technologies, Inc. By Attorneys for the Applicant SPRUSON & FERGUSON Per:
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/657656 | 2012-10-22 | ||
US13/657,656 US9471370B2 (en) | 2012-10-22 | 2012-10-22 | System and method for stack-based batch evaluation of program instructions |
Publications (2)
Publication Number | Publication Date |
---|---|
NZ616299A NZ616299A (en) | 2015-04-24 |
NZ616299B true NZ616299B (en) | 2015-07-28 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220027195A1 (en) | System and method for batch evaluation programs | |
CA2829266C (en) | System and method for batch evaluation programs | |
US10534773B2 (en) | Intelligent query parameterization of database workloads | |
US11775520B2 (en) | Updating of a denormalized database object after updating, deleting, or inserting a record in a source database object | |
US20070143246A1 (en) | Method and apparatus for analyzing the effect of different execution parameters on the performance of a database query | |
US20070250517A1 (en) | Method and Apparatus for Autonomically Maintaining Latent Auxiliary Database Structures for Use in Executing Database Queries | |
JP7465870B2 (en) | System and method for dependency analysis in a multidimensional database environment - Patents.com | |
US10191947B2 (en) | Partitioning advisor for online transaction processing workloads | |
US20230214393A1 (en) | Query execution including pause and detach operations after first data fetch | |
US20190213188A1 (en) | Distributed computing framework and distributed computing method | |
CN107209764B (en) | Rules for specifying and applying data | |
US11816020B2 (en) | Online query execution using a big data framework | |
Almeida et al. | Performance analysis and optimization techniques for Oracle Relational Databases | |
US10102243B2 (en) | Specification of database table relationships for calculation | |
NZ616299B (en) | System and method for batch evaluation programs | |
WO2021143199A1 (en) | Method and apparatus for searching log, computer device, and storage medium | |
CN117193990B (en) | Scheduling management method, device, equipment and storage medium of http interface | |
NZ616212B (en) | System and method for batch evaluation programs | |
US20230418657A1 (en) | Runtime prediction for job management | |
US20230359671A1 (en) | Reparallelization for workload skewing database operations | |
US10534774B2 (en) | Query performance degradation analysis timing |