[thesite] if anyones bored..

[.jeff]

joshua,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Joshua Olson
>
> : well, in general terms, that's what a huge majority
> : of time of *any* page is 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?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i'm talking about the sidebar (which is built for *every* page request)
versus the main content area.  there are now a ton of queries necessary to
render any given page.  there are definitely some things that could be done
to improve this situation alone.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> : some of the time incurred in rendering the homepage
> : is time spent also rendering other pages on the site.
>
> This does not make sense to me.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

see above.  does that make more sense now?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> : 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.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i agree.  the php counterpart probably is much faster.  i'm also sure, using
cf5, most of these custom tags could be replaced by user-defined functions
making the impact of the calculations these custom tags perform next to
nothing.

however, in order for it to be a fair comparison, it'd have to be a
feature-for-feature match.  a flat page versus a feature-rich cms (and the
performance you take for those features) isn't a fair comparison.  unless
you use a completely different application architecture, you'll still have
to deal with php includes and their requisite performance hit.  again, for
it to be a fair comparison, the php version of the cms would have to be
implemented in a similar fashion.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> : 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.  [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that's all i'm saying.  make it produce the same results, across the board.
this goes back to what i was saying though -- a fair comparison would
require the entire cms be written in php to be functionally identical.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> : 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.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i'm not doubting that they could.  all i'm saying is that they have to be
there in the php version for an accurate comparison.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 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?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

which begs an alternate question -- would it help everyone understand it
better if it were in another language?  i highly doubt it.  it's a complex
architecture.  if you're not experienced in the language the application is
built with, you're not likely to understand the complexities of it.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 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.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

sorry to say, but changing languages won't make it easier for more people to
understand.  it will only change the group of "experts" that are comfortable
making changes to the application.

as for limitations of the current architecture, there have been a ton of
things learned about this architecture since we built this version of the
cms about a year ago.  there are also a bunch of efficiencies we can take
advantage of in cf 5.0.  additionally, there are things about the cms that
we understand much better now and could change in it to make it more
efficient.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/