nitish pandey wrote:
I am not taking a stand but i know that it is said that CF is slow
even though it might very well be an outdated point. That is my point,
that that outdated stand remains alive. What should be done to sweep
it away?
Mmm ... i haven't heard the "cfml is slow" in absolute years. You are
the first one to bring it up to me. So i am not sure where this is
being discussed. Maybe when you do hear it, you simply say to people
that they should reevaluate their stance and give the engines another go.
In my experience, when the engine was running slow, it was down to the
poor development of the CFML application, not the underlying engine.
CFML is powerful, and to that end, it can give people who really don't
know how to write high performance apps, the ability to create a lot of
problems for themselves.
Did you also not say, in this mail of yours, that PHP is chosen for
it's freeness and IDE etc. rather than performance...does that mean
performance wise PHP is also on a weak wicket as CF but because of the
rather powerful networks and hardware we have that should not matter?
Is that your case?
No that is not my case in the slightest. You are making the mistake of
2 + 2 = 22. A poorly written PHP app will perform poorly as any
other language.
We face terrible amount of dropped requests on my e-commerce
www.semiprecious.com <http://www.semiprecious.com> despite huge RAM.
Currently on ACF. Fearful to move it to openBD....will openBD be
slower? Cryptic to debug (socket/ODBC pooling/caching...in that
esoteric domains)?
Mmm well i can see for a start that if you are using ODBC in your
database then you are going to have problems. I cannot honestly tell
you if you app is going to run faster or slower. I have no knowledge
how well coded your application is, how well you have optimized your
queries, structured your code. So really the only person that can tell
this is you.
--
official tag/function reference: http://openbd.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
