Yes, I see how that could scale well.

But...
It still seems like that initial parsing run could be laborious. So in the 
case of a large, complex, or poorly-written template, the time required for 
that step could be worth considering.

As I said, for readability, I tend towards ridiculously long identifiers. 
It seems like in the olden days, compilers would replace those with 
pointers of some sort, so there was no real penalty for them being 
ridiculously long.
Also, I tend to scope almost all of my variables these days. Instead of 
"MyVariable" it's now "variables.MyVariable". I read somewhere that speeds 
things up, and that makes sense to me. CF has to figure out the scope of 
everything anyhow. So does that pre-compile step also take care of scoping 
everything? Seems like it would need to.  And if so, that would move the 
penalty for failing to scope your variables from the valuable execution 
time to the "who cares" pre-compile time.

yes/no?

tx,
c

On Saturday, August 11, 2012 6:18:07 AM UTC-5, Alan Williamson wrote:
>
> I understand what you are saying ... and yes, while OpenBD does not 
> compile directly to byte code per se, it does indeed go through an 
> internal compilation.   This is where "interpreted" gets misused a lot, 
> usually by those trying to labor a point that it is slower. 
>
> OpenBD does compile your template upon first load, removing all the 
> unnecessary fluff and organizing things in a manner that when we handle 
> the request it is as fast as possible.   Every request that comes in, 
> does NOT incur this overhead and you are running against our internal 
> representation of the page/cfc. 
>
> We have highly optimized this process over the 12years we've been doing 
> this, to take advantage of how people execute requests and to optimize 
> memory usage.  This is how we scale to extremely large loads more 
> efficiently than other alternatives.  We've always designed for the 
> large floods, not the trickles. 
>
>
> On 11/08/2012 03:47, Confused wrote: 
> > I'm not interested in hiding my source. Good luck to the moron that 
> > steals my code. Let me know how that 1st update worked out. :) 
> > 
> > I was just interested in the pre-compiling part for faster execution. 
>
>

-- 
online documentation: http://openbd.org/manual/
 http://groups.google.com/group/openbd?hl=en

Reply via email to