[thesite] if anyones bored..

Joshua Olson joshua at alphashop.com
Sat Oct 20 19:00:53 CDT 2001

----- Original Message -----
From: ".jeff" <jeff at members.evolt.org>
Subject: RE: [thesite] if anyones bored..

: joshua,
: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
: > From: Joshua Olson
: >
: > Underpinnings aside, a huge majority of the time spend
: > on rendering the homepage falls into two tasks:
: >
: > 1. Querying the information
: > 2. Generating the screen display
: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
: well, in general terms, that's what a huge majority of time of *any* page
: spent doing.  getting more specific though is identifying what's being
: queried and generating display on the screen.

"identifying what's being queried"?  What does this mean, and why are you
point it out?  Is it slow?

: some of the time incurred in
: rendering the homepage is time spent also rendering other pages on the

This does not make sense to me.

: there also the time penalties for includes and custom tags that would need
: to be accounted for as well as all the calculations that happen in
: application.cfm for each request.

Why do you need to account for time spent in custom tags?  Custom tags are
slow, and I'd bet that the PHP counterpart is much faster.

: in order for it to be a fair comparison it couldn't be the current cms
versus a flat page request.

Why not?  Just make sure the PHP version produces the same results based on
the input.  Why would this not be fair?

: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
: > With the current Evolt CMS I know that there are a few
: > items that happen with every page request (such as
: > session state management, 404 management, etc), and I'm
: > sure you could isolate how long those items are taking
: > to complete and remove them from the comparison.
: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
: simply calculating their impact on the total and then taking the different
: as the processing time for the rest would be naive.  there's no telling
: much the time of the remainder would be affected if the portions removed
: from the total time never took place to begin with.

Fine, whatever.

: for example, there's lots of calculations for session state management
: happens in application.cfm.  that's there so that content display can make
: choices about what's displayed to the end user with respect to their level
: of authorization.  in order for it to be a fair comparison, the php
: would need to do this as well.

Okay, agreed...

: these sorts of dependencies are throughout the site.  that's why simply
: making a php page that queries the information and renders it onscreen
: wouldn't be a valid comparison.

Huh?  The dependencies you are talking about are O(1) in most cases.  That
means, each page request, no matter what is requested, is affected the same
by these dependencies.  I want to see if PHP would run these "dependencies"
faster.  I'd bet they will.

: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
: > Part of me is convinced that a PHP version of the
: > homepage might run a whole lot faster than the CF
: > version that's there now.  Mind you, I'm not suggesting
: > that evolt change platforms, but lately I have been
: > having doubts as to CF's processing power, but I do
: > not know enough PHP to make that version myself.
: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

: the total processing time is not the total equation for the power of an
: application server.  you must also take into account the speed with which
: you can develop and maintain the application.  while php may win the
: rendering time race, i'm quite certain it would lose the development and
: maintenance time races -- especially where less experienced developers (cf
: or php) are concerned.

Ok, so this begs a question for everybody:

Raise your hand if you have mastered CF and feel comfortable making serious
changes to the current system?  Does anyone other than jeff and a select few
truly understand SSURL and the architecture?

Not trying to attach you, jeff, but you stepped up to bat.  I know the
limitations of the current architecture just as you do, and I've become very
disenchanted with CF's string handling and rendering time of HTML.  I *hope*
all this changes with CF 5.0, but so far I'm not impressed.


More information about the thesite mailing list