Probably not. One thing that is increasingly important (judging from
questions I get giving talks) is how to do XP/test driven development in
Laszlo - i.e. how does LzUnit work and how is it best utilized...
-Max
John Sundman wrote:
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]
