Visualizing Dynamic Metrics with Profiling Blueprints

Visualizing Dynamic
Metrics with Proﬁling
Blueprints
Alexandre Bergel, Romain Robbes, Walter Binder
University of Chile University of
Chile Lugano

“software proﬁling is the investigation
of a program's behavior using
information gathered as the program
executes”
- Wikipedia

2

{ {
{ {
}
}
}
} { }

3

{ {
{ {
}
}
}
} { }

4

1.4
{ {
{ {
}
}
}
} { }

5

1.4
{
5.2
{
{ {
}
}
}
} { }

6

1.4
{
5.2
{
{
}
}
{
} 5.6
} { }

7

1.4
{
5.2
{
{
}
}
{
} 5.6
} { }
2.3

8

1.4
{
5.2
{
{
}
}
{
} 5.6
} { }
2.3
0.5
...

9

1.4
{
5.2 }
{
5.6
}
{ { }
} } {
}
} } {

2.3
{
} { } {
{

0.5
... Understanding why

10

gprof: ﬂat proﬁle
Flat profile:

Each sample counts as 0.01 seconds.

% cumulative self self total

time seconds seconds calls ms/call ms/call name

33.34 0.02 0.02 7208 0.00 0.00 open

16.67 0.03 0.01 244 0.04 0.12 offtime

16.67 0.04 0.01 8 1.25 1.25 memccpy

16.67 0.05 0.01 7 1.43 1.43 write

16.67 0.06 0.01 mcount

0.00 0.06 0.00 236 0.00 0.00 tzset

0.00 0.06 0.00 192 0.00 0.00 tolower

0.00 0.06 0.00 47 0.00 0.00 strlen

0.00 0.06 0.00 45 0.00 0.00 strchr
11

gprof: call graph (~1984)
index % time self children called name
<spontaneous>
[1] 100.0 0.00 0.05 start [1]
0.00 0.05 1/1 main [2]
0.00 0.00 1/2 on_exit [28]
0.00 0.00 1/1 exit [59]
-----------------------------------------------
0.00 0.05 1/1 start [1]
[2] 100.0 0.00 0.05 1 main [2]
0.00 0.05 1/1 report [3]
-----------------------------------------------
0.00 0.05 1/1 main [2]
[3] 100.0 0.00 0.05 1 report [3]
0.00 0.03 8/8 timelocal [6]
0.00 0.01 1/1 print [9]
0.00 0.01 9/9 fgets [12]
0.00 0.00 12/34 strncmp <cycle 1> [40]
0.00 0.00 8/8 lookup [20]
0.00 0.00 1/1 fopen [21]
0.00 0.00 8/8 chewtime [24]
0.00 0.00 8/16 skipspace [44]
-----------------------------------------------
[4] 59.8 0.01 0.02 8+472 <cycle 2 as a whole>! [4]
0.01 0.02 244+260 offtime <cycle 2> [7]
0.00 0.00 236+1 tzset <cycle 2> [26]
-----------------------------------------------
12

Retrospective on proﬁling

Information conveyed hasn’t evolved since gprof
Useful to understand what happened
But is of little help to understand why and how

18

Roadmap

1.Polymetric views
2.Proﬁling Blueprint
3.Implementation

19

Polymetric view can map up to 5
dimensions
width property

color height
property property
X property

Y
property

[Lanza 2003] 20

KaiProfiler
viewProfiling: [
| view |
! view := MOViewRenderer new.
! view
nodes: (1 to: 100)
forEach: [:each |
view nodes: (1 to: 100)].
! view root applyLayout
! ]

21

Structural blueprint

legend for methods
# executions

(color)
execution
#different
time
receiver

22

Structural blueprint

bounds

legend for methods
# executions

(color)
execution
#different
time
receiver

23

Behavioral blueprint

legend for methods
# executions

gray =
return m1 m3
self
execution m1
time yellow = invokes
constant m2 m2 and m3
on return
value
24

Behavioral blueprint

legend for methods
# executions

gray =
return m1 m3
self
execution m1
time yellow = invokes
m2 m2 and m3
bounds
constant
on return
value
25

Detailed behavioral blueprint

computeExtentHavingChildrenFor:

MOGraphElement>>
origin

Calling #bounds

bounds

Called by #bounds
shapeBoundsAt:ifPresent:

26

Code of the bounds method

MOGraphElement>>bounds
"Answer the bounds of the receiver."

| basicBounds |

self shapeBoundsAt: self shape ifPresent: [ :b | ^ b ].

basicBounds := shape computeBoundsFor: self.
self shapeBoundsAt: self shape put: basicBounds.

^ basicBounds

27

Memoizing

"Answer the bounds of the receiver."

| basicBounds |
boundsCache ifNotNil: [ ^ boundsCache ].
self shapeBoundsAt: self shape ifPresent: [ :b | ^ b ].

basicBounds := shape computeBoundsFor: self.
self shapeBoundsAt: self shape put: basicBounds.

^ boundsCache := basicBounds

28

Upgrading

A

B
C

29

43%
speedup Upgrading

A

B
C

30

A

Upgrading

B

31

B C
A

cached
absoluteBounds
instea

A'

C'

B'

C'

32

Implementation

We use the following metrics:
execution time for a method (% and ms)

number of executions

number of different object receivers

Dynamic properties
a method performs a side effect

a method is void (i.e., return self in Pharo)

33

Naive (but effective) implementation

Code to proﬁle is executed twice
using a sampling method to get the execution time

instrumentation to get all the remaining metrics

Use hash values to distinguish between different
receiver objects
Built a kind of AOP mechanism for the low level
instrumentation

34

Implementation techniques

Visualizations are generated using a scripting
languages
... in Mondrian

Limitation
hash code collisions (problem in Pharo)

need to do execute the code to proﬁle twice (sampling and
instrumentation)

35

Implemented in Pharo
Smalltalk dialect
Dynamically typed language

36

Conclusion

Effective visualizations
Smooth integration in the programming environment
Implemented in Pharo

37

Conclusion

A number of bottlenecks were identiﬁed
No general rule for pattern identiﬁcation
Visualizations are effective for identifying potential
candidate for optimization

38

Conclusion

Future work
close integration in the programming environment

dedicated visualization for comparison

additional metrics, e.g., the number of executed bytecodes,
memory usage

39

Visualizing Dynamic Metrics with Proﬁling
Blueprints

www.moosetechnology.org/tools/Spy

A Alexandre Bergel, Romain Robbes,
Walter Binder
B

C

abergel@dcc.uchile.cl
40

Visualizing Dynamic Metrics with Profiling Blueprints

More Related Content

Similar to Visualizing Dynamic Metrics with Profiling Blueprints (20)

More from ESUG (20)

Recently uploaded (20)

Visualizing Dynamic Metrics with Profiling Blueprints