I just wanted to confirm that the bottlenecks I have come across have always pointed to the OO queries being the culprit. I haven't posted about it here as I was hoping to dig a little deeper so that I could offer a little more useful info in that regard. However, in certain cases I used the OO query and then just modified the customizable gateway with the same query in a custom method. I expected that the performance would be better on the latter, as it seems obvious it would. However, the difference was much more dramatic than I expected. I don't have the exact numbers on me right now, but the OO query was somewhere in the thousand plus millisecond area and the customized method was a hundred plus. Keeping in mind that I did not have trusted cache turned on, and in fact had debugging on, this still was a larger difference than I expected.
- Brian
From: "Doug Hughes" <[EMAIL PROTECTED]>
Sent: Thursday, March 02, 2006 8:43 AM
To: [email protected]
Subject: RE: [Reactor For CF] speed of the framework
William,
A few stream of consciousness thoughts for you:
1) Try that same test with trusted cache turned on. There are a lot of CFCs
in Reactor. CF needs to check each one at runtime to see if it's changed.
This is expensive. I've seen dramatic improvements with trusted cache
turned on. (I don't have it running on doughughes.net).
2) Reactor will be slower than just running your queries. Right now I'm not
pleased with performance. I have a pretty good idea where the bottlenecks
are. I think they're primarily in the OO queries. I haven't had *any* time
to look into this. I'd planed to make Reactor feature complete before I
worked on performance issues.
3) I'm using Reactor in three production apps now. Two are with MG (one of
those with ColdSpring). One is with no framework at all. With the MG apps
I've been very happy with speed so far (but the relationships in the xml are
not complicated (yet)). The no-framework app is more complicated and I've
been displeased with performance.
4) A more useful comparison of speed would be to code your own gateways,
doas, etc. Then run reactor in production mode side-by-side and compare
speeds. I'm sure the hand-written code will be faster right now. But it'd
be interesting to see what the differences are and what your code doesn't
have. That might help identify some of the bottlenecks in Reactor.
5) The most useful thing you could do would be to use the latest code and
spend some time trying to track down what makes it run slowly. Submit
enhancements that will speed the framework up. These will be greedily
accepted.
Doug
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William
Langshaw
Sent: Wednesday, March 01, 2006 10:51 PM
To: [email protected]
Subject: [Reactor For CF] speed of the framework
Hello-
I have a basic Reactor setup. For some testing purposes I have one
table, "Person" with a couple of obvious columns. I have a very basic
page which creates a PersonGateway and does two things:
First off, my table only has 2 rows in it and the firstname like 'co%'
only matches 1 person.
With the Reactor factory placed in App scope in Application.cfc and
with debugging turned off and with reactor in "production" mode, this
page takes ~125ms to run. Running both queries on their own via
cfquery takes on the order of a few milliseconds each.
I realize that the framework's purpose is to decrease repetitive
typing and its in Alpha stage (so performance tweaks are not high on
the priority list) but it seems that the overhead is a lot. Factor in
other frameworks like Model-Glue or MachII and at the end of the day,
the response time is high! (The example above is very trivial. I
proof-of-concepted a "Person Profile" page under MachII displaying a
person's email, user info, company info, company address info, and the
whole thing takes 3 seconds to run with most of the overhead going to
Reactor as I have benchmarked MachII on its and can say that its not
the bottleneck.)
I am just wondering, to what degree has anybody used Reactor in the
real-world and have they been able to realize acceptable performance?
Doug, dont get me wrong, you have done an incredible job and put
together quite an advanced package. I am not knocking all your hard
work, but am just trying to evaluate Reactor from a neutral
perspective.
I realize that Reactor is Alpha, so is there any intention to address
performance down the line? Or is this it? I am familiar with the
processing cycle of MachII and for all it does, its fast. I just cant
see what the bottlenecks for Reactor are. When I turn on debugging in
CF, the numbers are all over the place and ever changing, so its very
difficult to trace it down to any 1 or 2 or places.
As it stands, I love Reactor for the power it offers me and the
ability to quickly code up the data access layer, but its performance
is not acceptable for the sites we are developing, much to my dismay.
Is my above code wrong, can it be optimized or is this as good as its
going to get?
Hoping for answers!
William
-- Reactor for ColdFusion Mailing List -- [email protected]
-- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
-- Reactor for ColdFusion Mailing List -- [email protected]
-- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
