Domain-Specific Profiling - TOOLS 2011
Download as KEY, PDF1 like791 views
Traditional profilers provide CPU time profiling information but do not provide insight into which specific domain objects are responsible for performance issues. Domain-specific profilers address this by instrumenting the domain of interest to capture runtime information about specific domain objects and their behavior, then presenting the results in a way that relates performance to the domain. This allows pinpointing which objects are actually causing performance problems rather than just methods or code sections.
![lit tle impact on the overall execution. T his sampling technique is u
all mainstream profilers, such as JProfiler, Your K it, xprof [10], an
Message Tally, the standard sampling-based profiler in Pharo Sm
tually describes the execution in terms of C P U 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](https://image.slidesharecdn.com/metaspytools2011-110629103702-phpapp01/85/Domain-Specific-Profiling-TOOLS-2011-10-320.jpg)
![Domain-Specific P rofiling 3
C P U t i me p rofiling
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.
E xecution 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
lit tle impact on the overall execution. T his sampling technique is used by almost
all mainstream profilers, such as JProfiler, Your K it, xprof [10], and hprof.
Message Tally, the standard sampling-based profiler in Pharo Smalltalk 2 , tex-
tually describes the execution in terms of C P U 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. T his
general profiling information says that rendering nodes and edges consumes a
great share of the C P U 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 ob ject that received
the method call and its arguments. As a consequence, it is hard to track down
which ob jects 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.
C overage
Petit Parser is a parsing framework combining ideas from scannerless parsing,](https://image.slidesharecdn.com/metaspytools2011-110629103702-phpapp01/85/Domain-Specific-Profiling-TOOLS-2011-11-320.jpg)
![MondrianProfiler>>setUp
self model root allNodes do: [ :node |
self
observeObject: node
selector: #displayOn:
do: [ ... counting ... ] ]](https://image.slidesharecdn.com/metaspytools2011-110629103702-phpapp01/85/Domain-Specific-Profiling-TOOLS-2011-34-320.jpg)
![PetitParserProfiler>>setUp
self model allParsers
do: [ :parser |
self
observeParser: parser
in: self grammar
do: [ ... counting ... ] ]](https://image.slidesharecdn.com/metaspytools2011-110629103702-phpapp01/85/Domain-Specific-Profiling-TOOLS-2011-37-320.jpg)
Domain-Specific Profiling - TOOLS 2011
- 1. Domain-Specific Profiling Alexandre Bergel, Oscar Nierstrasz, Lukas Renggli and Jorge Ressia
- 2. Profiling: Is the activity of analyzing a program execution.
- 4. Profile Source Report
- 5. Examples
- 6. CPU time
- 7. Mondrian
- 9. o mpl exity S m C ucasse 2003 yste d D n Lanza a
- 10. lit tle impact on the overall execution. T his sampling technique is u all mainstream profilers, such as JProfiler, Your K it, xprof [10], an Message Tally, the standard sampling-based profiler in Pharo Sm tually describes the execution in terms of C P U 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
- 11. Domain-Specific P rofiling 3 C P U t i me p rofiling 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. E xecution 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 lit tle impact on the overall execution. T his sampling technique is used by almost all mainstream profilers, such as JProfiler, Your K it, xprof [10], and hprof. Message Tally, the standard sampling-based profiler in Pharo Smalltalk 2 , tex- tually describes the execution in terms of C P U 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. T his general profiling information says that rendering nodes and edges consumes a great share of the C P U 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 ob ject that received the method call and its arguments. As a consequence, it is hard to track down which ob jects 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. C overage Petit Parser is a parsing framework combining ideas from scannerless parsing,
- 12. Coverage
- 14. Java Grammar 210 Methods 100% coverage to build grammar
- 16. Java Grammar 210 Methods 100% coverage to build grammar Is each production of the grammar covered?
- 17. Profile Source Report Domain
- 18. Domain Source Traditional Code Profilers
- 19. Domain-Specific Domain Profilers Source Traditional Code Profilers
- 20. What does it mean?
- 21. Specify
- 22. Capture
- 23. Present
- 24. MetaSpy
- 25. Instrumenter Profiler
- 26. Domain Domain Object Domain Object Domain Object
- 27. Domain Domain Object Domain Object Domain Object
- 28. Domain Domain Object Domain Object Domain Object
- 29. Instrumentation strategies Profilers MetaInstrumenter Profiler handler model install strategies setUp observeClass:do: tearDown observeClass:selector:do uninstall observePackage:do: observePackagesMatching:do: observeParser:in:do: install Announcement MethodInstrumenter ParserInstrumenter setUp Instrumenter theClass parser tearDown announcer selector grammar uninstall install methdo replacement uninstall doesNotUnderstand: install run:with:in: uninstall install setUp MondrianProfiler OmniBrowserProfiler PetitParserProfiler tearDown setUp setUp setUp uninstall visualize visualize visualize User provided classes
- 30. Specify the Domain interests Capture the runtime information Present the results
- 33. o mpl exity S m Ccasse 2003 yste Du Lanza,
- 34. MondrianProfiler>>setUp self model root allNodes do: [ :node | self observeObject: node selector: #displayOn: do: [ ... counting ... ] ]
- 36. Profiler
- 37. PetitParserProfiler>>setUp self model allParsers do: [ :parser | self observeParser: parser in: self grammar do: [ ... counting ... ] ]
- 39. Implementation
- 40. Instrumentation
- 41. Two options Hooking to the Domain Reflection
- 42. Reflection
- 43. scg.unibe.ch/research/ bifrost
- 46. Class Instrumentation Meta-object Object
- 47. Class Instrumentation Meta-object Object
- 48. Class Instrumentation Meta-object Instrumented Object
- 49. Partial Reflection Selective Reifications Unanticipated Runtime Integration Adaptation Composition
- 50. Profile Source
- 51. Profile Source
- 53. MetaSpy Domain- Domain Specific Profilers Source Traditional Code Profilers
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: Code profilers commonly employ execution sampling as the way to obtain dynamic run-time information\n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: What is the relationship between this and the domain? picture again\n
- #12: \n
- #13: PetitParser is a parsing framework combining ideas from scannerless parsing, parser combinators, parsing expression grammars and packrat parsers to model grammars and parsers as objects that can be reconfigured dynamically.\n
- #14: Rigorous test suites try to ensure that each part of the grammar is covered by tests and is well-specified according to the respective language standards. Validating that each production of the grammar is covered by the tests is a difficult activity. As mentioned previously, the traditional tools of the host language work at the method and statement level and thus cannot produce meaningful results in the context of PetitParser where the grammar is modeled as a graph of objects.\n
- #15: This is a picture of the XML grammar\n
- #16: Rigorous test suites try to ensure that each part of the grammar is covered by tests and is well-specified according to the respective language standards. Validating that each production of the grammar is covered by the tests is a difficult activity. As mentioned previously, the traditional tools of the host language work at the method and statement level and thus cannot produce meaningful results in the context of PetitParser where the grammar is modeled as a graph of objects.\n
- #17: \n
- #18: new dimension of problem-domain\n
- #19: new dimension of problem-domain\n
- #20: Specify the Domain interests\n Capture the runtime information\n Present the results\n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n\n
- #27: \n\n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: Clicking and drag-and-dropping nodes refreshes the visualization, thus increasing the progress bar of the corresponding nodes. This profile helps identifying unnecessary rendering. We identified a situation in which nodes were refreshing without receiving user actions.\n
- #34: \n
- #35: What does observeParser do?\n
- #36: \n
- #37: \n
- #38: Software instrumentation monitors the run-time behavior of a system to support a particular kind of analysis.\n
- #39: \n
- #40: \n
- #41: \n
- #42: We see that there are many different ways of doing reflection, adaptation, instrumentation, many are low level.\nAnd the ones that are highly flexible cannot break free from the limitations of the language.\n
- #43: Adaptation semantic abstraction for composing meta-level structure and behavior.\n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: \n
- #49: \n
- #50: We need to reflect on the dynamic representation of a program, that is, the operational execution.\nThis is called Behavioral Reflection pioneered by Smith in the context of Lisp\n
- #51: Behavioral reflection provides a way to intercept and change the execution of a program. It is concerned with execution events, i.e., method execution, message sends, or variable assignments. \n
- #52: \n
- #53: \n
- #54: Code profilers commonly employ execution sampling as the way to obtain dynamic run-time information\n
- #55: Code profilers commonly employ execution sampling as the way to obtain dynamic run-time information\n
- #56: \n
- #57: 1. identified the need for domain-specific profiling\n2. empirical validation of domain-specific profiling\n3. presented an infrastructure for domain-specific profiling\n