It's more like this:
1) Procedure X was created to define a generic
and standard way to remove the fusebox architecture
from a fusebox app.
2) Application A was a FB'd application.
3) Application A took 60ms to run.
4) Application B was Application A after removing
the FB architecure (following Procedure X).
5) Application B took 50ms to run.
6) Therefore, in this test case, the fusebox
application peformed 20% slower than the
non-fusebox equivalent.
Steps 2-6 could be repeated as many times as you
like (substituting a different application each
time for application A), and the average of the
results would be more useful with each iteration.
Hal's suggestion (if I understand correctly) is
like this:
1) Developer 1 is a "good" developer.
2) Developer 2 is a "good" fusebox developer.
1) Application A was not fuseboxed, but was written
by a developer 1.
2) Application A took 50ms to run.
2) Application B was application A rewritten in
fusebox by developer 2.
3) Application B took 45ms to run.
How could this be? The results are tainted,
because the value of "good" is unknown. Perhaps
Developer 2 was actually slightly better than
Developer 1.
Perhaps either developer 1 or developer 2 was
biased, and that bias affected the quality of
his work. (This is especially likely if
developer 1 and developer 2 are the same
person.)
Or perhaps the act of breaking the app down to
smaller pieces made the logic more clear for
developer 2, and therefore he was able to do a
better job, even though he is equally as "good"
as developer 1. (I think this is what Hal is
trying to get at, but there are too many
uncontrolled variables and the experiment
doesn't sufficiently "prove" anything.)
Patrick
> -----Original Message-----
> From: Stacy Young [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 23, 2001 10:01 AM
> To: Fusebox
> Subject: RE: Why Benchmark?
>
>
> I guess it would be difficult to use the test results if they
> were presented
> like:
>
> a) Application A was non-FB and took 50ms to load.
> b) Application B was FB (but we removed the FB architecture) and took 50ms
> to load.
>
> Results: An app which was a FB design then re-fitted to resemble the
> architecture of a non-FB was just as fast as the non-FB application.
>
> :)
>
> (ok ok an over-simplification but u get my point...no?)
>
>
> -----Original Message-----
> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 23, 2001 9:35 AM
> To: Fusebox
> Subject: RE: Why Benchmark?
>
>
> > Well, it may be that we just have different goals.
> Actually, I don't have a goal. I was suggesting a way to help with your
> goal. :)
>
> > My goal is NOT to see how
> > much faster a fusebox app would be without the overhead, but to see in
> > a real-world application, the speed differences between FB and non-FB.
>
> Enlighten me, your Halness! How is "the speed difference between FB and
> non-FB" different from "how much faster a fusebox app would be without the
> overhead"? I can't wait to see the actual test. Maybe that
> will clear it up for me.
>
> Patrick
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
