On 11 June 2010 15:59, Colin Strickland <[email protected]> wrote: > As ever, there's no such thing as a magic answer. I don't disagree with > anything you say, but you don't always have that luxury of choice. > > Sometimes, when you are programming for the web in the large, execution time > is considerably significant. Admittedly, most people don't work at this > scale. I myself > have worked on some moderately busy web apps before, and consequently spent > much time doing ugly computational things I disliked inside the presentation > layer. > > You need to optimise in the right areas. Look at Facebook and their bazillion > lines of PHP templating and native PHP compiler. Look also at Twitter, with > their > beautiful MVC RoR roots, and their recurrent whale pictures.
I've worked on some pretty busy sites, but none busy enough to reach the point where the page templating speed of Mason or TT had any impact (unlike IMDB where even relatively little costs per request can add up to make a noticable difference). OTOH I've seen plenty of handrolled inhouse templating systems totally fail to scale or suddenly degrade badly in performace when core perl fixes or changes regular expression implementation details that were being relied on by the original programmer. It's all about bottlenecks and designing for scaling (rather than performance), if you have a sensible caching strategy and pre-build snippets, etc then TT can be blindingly fast, and still provide awesome benefits in terms of ease of development. The main thing to remember is that technology can't (usually) solve bad design decisions, good design is considerably more likely to scale and perform well, and be easier to improve/tune/pimp when you need to. A. -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
