Peter that was more of a theoretical guess than an actual statement
but I will reenforce it.

My assumptions based on how C compilers work.

There is a preprocessing phase for a individual page call.


Step one, preprocess any individual CF template include any
files into the template do anything else (syntax checking
after the inclusion, before the inclusion) there are to
many things to talk about so ill just stick to including files.

After "pre processing" you now have a template to be interpreted.

The next phase since we all know that CF "compiles" templates
to PCode is to turn that template into PCode.

So one Section of my site may have 10 fuses which is really
just 10 seperate Compilations (10 different file configurations)

Again most of this is theory if anyone actually knows I would
love to hear it, im just taking some guesses here.

At this point I can only state guesses since I am not entirely
certain. Dave? Allaire people?

Anyone care to comment on how this works.

My guess is say you have 30 different combinations to
CF that is just 30 different PCode compilations not so
many to leave in memory.

If it parses a template and finds it has changed or
has a different combination of CFINCLUDES I imagine
it just compiles a newer version. This is memory
intensive but is what gives lightning fast runtimes
even for fusebox stuff...

Its a really good question actually Peter and one I have
wanted someone to comment on every time I have mentioned
this.

BTW I realize the actual CFENGINE is much more complex I am
just grossly simplfying it for my example.

If that is not how it works I dont see how Fusebox and any
application using a lot of CFINCLUDES can get away with working
in an effecient manner. It somehow has to be translating the
pages to PCode or using some method of caching or combinations
thereof. Anyways someone enlighten us :)


Jeremy Allen
[EMAIL PROTECTED]


-----Original Message-----
From: Peter Theobald [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2000 4:47 PM
To: CF-Talk
Subject: Re: fusebox style: too much disk access?


That's the best possible case for cacheing. If everyone is acessing the same
file you can bet it will be in cache and will serve out quickly.

Did I understand Jeremy Allen correctly that the CF server will compile the
entire page to P-Code *with any included files* and cache it. How does it
track the myriad of combinations when all of the <cfinclude>s are dynamic
(inside CFIFs) and different files are included depending on the input and
data?

At 11:44 AM 10/20/00 -0400, Donald Sparks wrote:
>Okay, I'm not concerned with cfincludes and those related issues. I am
concerned with the handling of multiple requests on the index or "fusebox"
page (i.e.) a single page. For example say I have 1,000 users on my site. If
they are all accessing index.cfm as opposed to 20 to 30 different .cfm
pages. How does this affect caching and does it produce any other problems.
>
>Thank you,
>Don Sparks
>not quite at the 32nd chamber of fusebox.
>
>----- Original Message -----
>From: "Steve Nelson" <[EMAIL PROTECTED]>
>To: "CF-Talk" <[EMAIL PROTECTED]>
>Sent: Thursday, October 19, 2000 3:23 PM
>Subject: Re: fusebox style: too much disk access?
>
>
>> Don't be confused by what Nat is saying, a single "fuseaction" in a
>> Fusebox application may only hit 5-8 files.  It's really not that big a
>> deal.
>>
>> Steve
>>
>> Nat Papovich wrote:
>> >
>> > A simple test of included files suggests that CF's internal file access
>> > functions were pratically built with a cfinclude-heavy architecture in
>mind.
>> > Accessing dozens of files for a single page request is very quick. Out
>of
>> > 100 included files, you might notice a 10 ms increase than if you had
>all
>> > the code on the same page. Now that 10 ms performance hit gives you a
>> > scalable, intelligible architecture. If you have any experience with
>really
>> > large sites, you know that the only safe way to scale a project is to
>break
>> > it into small "minute modules".
>> >
>> > All this is without mentioning CF's ability to cache templates
>> > automatically. Accessing a file from RAM is basically instantaneous.
>> >
>> > If code scalability, readability, longevity, and understandability is
>> > important now or will be important later, you need to adopt a
structured
>> > application methodology like Fusebox.
>> >
>> > Nat Papovich
>> > ICQ 32676414
>> > "I'm for truth no matter who tells it."
>> > -Malcolm X, 1965
>> >
>> > -----Original Message-----
>> > From: Cyrill Vatomsky [mailto:[EMAIL PROTECTED]]
>> > Sent: Thursday, October 19, 2000 1:00 PM
>> > To: CF-Talk
>> > Subject: fusebox style: too much disk access?
>> >
>> > I was reading on the fusebox concept of putting minute modules into
>separate
>> > files and the question is: wouldn't that slow the site by having to
>access
>> > too many different disk files to load one page?
>> >
>> > Cyrill
>> >
>
>
>
>---------------------------------------------------------------------------
---------------------
>Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a
message with 'unsubscribe' in the body to [EMAIL PROTECTED]


---------------------------------------------------------------------------
Peter Theobald, Chief Technology Officer
LiquidStreaming http://www.liquidstreaming.com
[EMAIL PROTECTED]
Phone 1.212.545.1232 x204 Fax 1.212.545.0938

----------------------------------------------------------------------------
--------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a
message with 'unsubscribe' in the body to [EMAIL PROTECTED]

------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message 
with 'unsubscribe' in the body to [EMAIL PROTECTED]

Reply via email to