OK, should I be considering discussing this in the "peformance
monitoring" chapter of the Dguide? Or is this just for kernel
developers?
jrs
On Oct 25, 2006, at 1:40 PM, Benjamin Shine wrote:
Super-duper easy.
It's just lzx :) :) and it just uses getTimer(), which exists and
works in legals and trunk.
I've got a jsp cooking at home that does nice logging, and I'm
figuring out how to analyze the log. Seems like we want to be able
to analyze an individual run, and then store persistently the
*results* of log analysis.
I like java.
On Oct 24, 2006, at 10:26 PM, Jim Grandy wrote:
Very nice!
What are the prospects of porting this back to 3.x trunk? I'm
thinking about establishing a baseline against which to compare
Legals work, in addition to dhtml/swf comparisons.
jim
On Oct 24, 2006, at 4:27 PM, Benjamin Shine wrote:
Yep! Debug is totally unnecessary; I just happened to have it on
when I ran the tests that time. When I start recording, I'm
planning to record without debug on.
Yep, multiple runs of the tests are definitely in my plan, and
supported by measure.lzx. There should be a "quick metrics" that
we can run in a few seconds many times throughout the day, and a
"big metrics" that we can run as part of scheduled builds. I'll
need to tune it right to take an endurable amount of time.
On Oct 24, 2006, at 12:59 PM, P T Withington wrote:
Cool! Couple of comments:
Can you do this without debug? Debug adds a moderate penalty to
SWF and a huge penalty to dhtml. And you realize you should do
multiple runs to make sure you didn't accidentally intersect
with a time slice or garbage collection, right?
On 2006-10-24, at 15:37 EDT, Benjamin Shine wrote:
Just to start having something to look at, I made a little test
based on measure.lzx, which tests things of more relevance than
the last performance numbers I circulated. This measures
creating views, creating views from a class with a few levels
of hierarchy and some constraints, adding views to the canvas,
and creating a button and adding it to the canvas. Note that
the add* tests include the view creation.
Let it spin for maybe a minute after loading it; there are no
visible signs that it's running tests, until the test results
appear.
Server-side logging and analysis of performance test results is
next on my list. I have been looking around to see if something
already exists which meets our needs for performance benchmark
reporting and analysis, but, the things that exist seem to be
rather too complicated, heavyweight, and/or organized in a
different direction. Worthy of some investigation were JMeter
and Splunk, but neither are what we want here. It's another
case of "do the simplest thing that could possibly work."
When looking at the data -- the tests are not necessarily run
or reported in the same order in flash vs dhtml.
http://localhost:8080/legals/test/lfc/perf/viewperf.lzx?
lzr=swf7&debug=true
http://localhost:8080/legals/test/lfc/perf/viewperf.lzx?
lzr=dhtml&debug=true
My numbers right now (g5, firefox 1.5), of just one run, to
give you an idea of what the data look like:
swf7 with debug=true
view creation
For anyone wondering how to read these numbers, meters give
mean, deviation, min, max, iterations
newView 0.5 ±0
[ 0.5..0.5]/1
newBusyView 8.92 ±0
[ 8.92..8.92]/1
addViewsToCanvas 0.53 ±0
[ 0.53..0.53]/1
createComponent 24.82 ±0
[ 24.82..24.82]/1
addComponent 26.3 ±0
[ 26.3..26.3]/1
dhtml with debug=true
view creation
newView 2.46 ±0
[ 2.46..2.46]/1
newBusyView 22.2 ±0
[ 22.2..22.2]/1
addViewsToCanvas 6.4 ±0
[ 6.4..6.4]/1
createComponent 61.52 ±0
[ 61.52..61.52]/1
addComponent 72.8 ±0
[ 72.8..72.8]/1
Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
[EMAIL PROTECTED]