3. Profiling:
Is the activity of analyzing a program
execution.
Thursday, August 30, 12
4. Domain-Sp
CPU time profiling
Mondrian [9] is an open and agile visualization engine.
visualization using a graph of (possibly nested) nodes an
Profile
a serious performance issue was raised1 . Tracking down
performance was not trivial. We first used a standard sam
Execution sampling approximates the time spent in an
by periodically stopping a program and recording the cu
under executions. Such a profiling technique is relatively
little impact on the overall execution. This sampling techn
all mainstream profilers, such as JProfiler, YourKit, xprof
MessageTally, the standard sampling-based profiler in P
tually describes the execution in terms of CPU consumpt
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
{ { | 18.1% {3799ms} MOEdge>>displayOn:
{ { ...
} | 8.4% {1763ms} MOEdge>>displayOn:
}
}
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
} { } ...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent abou
the method displayOn: defined in the class MORoot. A ro
nested node that contains all the nodes of the edges of t
general profiling information says that rendering nodes a
great share of the CPU time, but it does not help in pin
and edges are responsible for the time spent. Not all grap
consume resources.
Traditional execution sampling profilers center their r
the execution stack and completely ignore the identity of th
the method call and its arguments. As a consequence, it
which objects cause the slowdown. For the example above,
says that we spent 30.9% in MONode>>displayOn: withou
were actually refreshed too often.
Coverage
PetitParser is a parsing framework combining ideas from
parser combinators, parsing expression grammars and pac
grammars and parsers as objects that can be reconfigured
Thursday, August 30, 12 1
http://forum.world.st/Mondrian-is-slow-next-step-tc
5. CPU time profiling
Mondrian [9] is an open and agile visualization engine.
Profile
visualization using a graph of (possibly nested) nodes an
a serious performance issue was raised1 . Tracking down
performance was not trivial. We first used a standard sam
Execution sampling approximates the time spent in an
by periodically stopping a program and recording the cu
under executions. Such a profiling technique is relatively
little impact on the overall execution. This sampling techn
all mainstream profilers, such as JProfiler, YourKit, xprof
MessageTally, the standard sampling-based profiler in P
tually describes the execution in terms of CPU consumpt
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
{ { 30.9% {6485ms} MONode>>displayOn:
{ { | 18.1% {3799ms} MOEdge>>displayOn:
} ...
}
} | 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
} { } | | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent abou
the method displayOn: defined in the class MORoot. A ro
nested node that contains all the nodes of the edges of t
general profiling information says that rendering nodes a
great share of the CPU time, but it does not help in pin
and edges are responsible for the time spent. Not all grap
consume resources.
Traditional execution sampling profilers center their r
the execution stack and completely ignore the identity of th
the method call and its arguments. As a consequence, it
which objects cause the slowdown. For the example above,
says that we spent 30.9% in MONode>>displayOn: withou
were actually refreshed too often.
Domain
Coverage
PetitParser is a parsing framework combining ideas from
parser combinators, parsing expression grammars and pac
grammars and parsers as objects that can be reconfigured
1
http://forum.world.st/Mondrian-is-slow-next-step-tc
a2261116
2
http://www.pharo-project.org/
Thursday, August 30, 12
8. C omp lexity
stemand Ducasse 2003
Sy zaLan
Thursday, August 30, 12
9. little impact on the overall execution. This sampling technique is u
all mainstream profilers, such as JProfiler, YourKit, xprof [10], an
MessageTally, the standard sampling-based profiler in Pharo Sm
tually describes the execution in terms of CPU consumption and i
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
| 18.1% {3799ms} MOEdge>>displayOn:
...
| 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent about 54% o
the method displayOn: defined in the class MORoot. A root is the
nested node that contains all the nodes of the edges of the visua
general profiling information says that rendering nodes and edge
great share of the CPU time, but it does not help in pinpointing
Thursday, August 30, 12
10. Domain-Specific Profiling 3
CPU time profiling
Which is the relationship?
Mondrian [9] is an open and agile visualization engine. Mondrian describes a
visualization using a graph of (possibly nested) nodes and edges. In June 2010
a serious performance issue was raised1 . Tracking down the cause of the poor
performance was not trivial. We first used a standard sample-based profiler.
Execution sampling approximates the time spent in an application’s methods
by periodically stopping a program and recording the current set of methods
under executions. Such a profiling technique is relatively accurate since it has
little impact on the overall execution. This sampling technique is used by almost
all mainstream profilers, such as JProfiler, YourKit, xprof [10], and hprof.
MessageTally, the standard sampling-based profiler in Pharo Smalltalk2 , tex-
tually describes the execution in terms of CPU consumption and invocation for
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
?
| 18.1% {3799ms} MOEdge>>displayOn:
...
| 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent about 54% of its time in
the method displayOn: defined in the class MORoot. A root is the unique non-
nested node that contains all the nodes of the edges of the visualization. This
general profiling information says that rendering nodes and edges consumes a
great share of the CPU time, but it does not help in pinpointing which nodes
and edges are responsible for the time spent. Not all graphical elements equally
consume resources.
Traditional execution sampling profilers center their result on the frames of
the execution stack and completely ignore the identity of the object that received
the method call and its arguments. As a consequence, it is hard to track down
which objects cause the slowdown. For the example above, the traditional profiler
says that we spent 30.9% in MONode>>displayOn: without saying which nodes
were actually refreshed too often.
Coverage
PetitParser is a parsing framework combining ideas from scannerless parsing,
parser combinators, parsing expression grammars and packrat parsers to model
Thursday, August 30, 12
grammars and parsers as objects that can be reconfigured dynamically [11].
26. When during the execution is this method called? (Q.13)
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed?
(Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point
in the code? (Q.28)
What parts of this data structure are accessed in this
code? (Q.33)
Thursday, August 30, 12
27. When during the execution is this method called? (Q.13)
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed?
(Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point
in the code? (Q.28)
What parts of this data structure are accessed in this
code? (Q.33) llito
Si etal. g softwar
e
ask durin
gr ammers s. 2008
Questi ons pro ution task
evol
Thursday, August 30, 12
28. Which is the relationship?
When during the execution is this method called? (Q.13)
?
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed? (Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point in the code? (Q.28)
What parts of this data structure are accessed in this code? (Q.33)
Thursday, August 30, 12
31. visualization using a graph of (possibly nested) nodes and edges. In June 2010
a serious performance issue was raised1 . Tracking down the cause of the poor
performance was not trivial. We first used a standard sample-based profiler.
Execution sampling approximates the time spent in an application’s methods
by periodically stopping a program and recording the current set of methods
Profiling
under executions. Such a profiling technique is relatively accurate since it has
little impact on the overall execution. This sampling technique is used by almost
all mainstream profilers, such as JProfiler, YourKit, xprof [10], and hprof.
MessageTally, the standard sampling-based profiler in Pharo Smalltalk2 , tex-
tually describes the execution in terms of CPU consumption and invocation for
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
?
| 18.1% {3799ms} MOEdge>>displayOn:
...
| 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent about 54% of its time in
the method displayOn: defined in the class MORoot. A root is the unique non-
nested node that contains all the nodes of the edges of the visualization. This
general profiling information says that rendering nodes and edges consumes a
great share of the CPU time, but it does not help in pinpointing which nodes
and edges are responsible for the time spent. Not all graphical elements equally
consume resources.
Traditional execution sampling profilers center their result on the frames of
the execution stack and completely ignore the identity of the object that received
the method call and its arguments. As a consequence, it is hard to track down
which objects cause the slowdown. For the example above, the traditional profiler
says that we spent 30.9% in MONode>>displayOn: without saying which nodes
were actually refreshed too often.
Coverage
PetitParser is
Thursday, August 30, 12 a parsing framework combining ideas from scannerless parsing,
32. Debugging
When during the execution is this method called? (Q.13)
?
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed? (Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point in the code? (Q.28)
What parts of this data structure are accessed in this code? (Q.33)
Thursday, August 30, 12
51. stack-centric debugging
InstructionStream class>>on:
InstructionStream class>>new
InstructionStream>>initialize
step into, CompiledMethod>>initialPC
step over, InstructionStream>>method:pc:
resume InstructionStream>>nextInstruction
MessageCatcher class>>new
InstructionStream>>interpretNextInstructionFor:
...
object-centric debugging
centered on centered on
the InstructionStream class the InstructionStream object
initialize
on:
next message, next message, method:pc:
new next change nextInstruction ...
next change
interpretNextInstructionFor:
...
Thursday, August 30, 12
57. Halt on next message
Halt on next message/s named
Halt on state change
Halt on state change named
Halt on next inherited message
Halt on next overloaded message
Halt on object/s in call
Halt on next message from
package
Thursday, August 30, 12
76. Back in time
Debugger
Debu gger
w
Floal. ECOOP 2008
O b ject nhard e
t
Lie
Thursday, August 30, 12
77. name value
init@t1 null
predecessor
name value
:Person field-write@t2 'Doe'
predecessor
name
value
field-write@t3 'Smith'
person := Person new t1
...
name := 'Doe' t2
...
name := 'Smith' t3
Thursday, August 30, 12