Actually it's a little more complicated than this.
There are 3 situations:
1) we need to copy a new tree of blocks and need to attach new contents
2) we can reuse a cached copy but need to attach new contents
3) we can reuse a copy and don't need to attach new contents
1 is the slowest, 2 is faster and 3 is the fastest.
I changed the mix of situations to minimize the number of case 1,
which increases case 2.
The problem with the test is that it doesn't properly measure the
speed of each case separately, nor the mix of cases that actually
occur in practice.
John
On Feb 13, 2007, at 11:48 AM, Heikki Toivonen wrote:
We had a major performance regression in the first time view
switching,
but at the same time improving subsequent view switching time. The
first
time view switching performance went from 1.01s to 3.06s, i.e. it got
about 3 times slower.
The same checkin also caused table scrolling to slow down on the
windows
test machine from 0.48s to 4.83s, i.e. about 9 times slower.
John argues to we should not be measuring the first time switch
performance.
We have continued to measure the first time performance for several
reasons:
* historical data
* We don't want the first time to be too slow either.
* It seems we have usage patterns were first time is actually not that
uncommon. Many people have half a dozen or more collections that they
overlaying with different calendars, and it seems every new
combination
is a "first time" performance. With that kind of usage you can
expect to
hit the "first time" case a couple of times a day for the first couple
of weeks I'd guess.
* There is also the case where people temporarily check different
calendars, in which case they hit this.
This is bug https://bugzilla.osafoundation.org/show_bug.cgi?id=7970
So, what are we going to do?
* Status quo
* Switch to measuring second time performance
* Measure both
If we make any changes to current practice, then other tests would
need
to change too.
--
Heikki Toivonen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
