General comment -- your thought process is starting to sound like premature optimization. :-) Is there an actual definable problem you're trying to solve here?
My recommendation would be don't worry about all of this unless you have to, which will likely be never. On Mon, Aug 13, 2012 at 3:06 PM, Confused <[email protected]> wrote: > 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 > -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca / Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en
