NYCPHP Meetup

[max goldberg]

I find that you take less of a performance hit dealing with templates
than you do with things like large db results that require a lot of
post-processing. While I usually use something a lot smaller and less
involved than Smarty, I feel with a cache/optimizer such as
Turck-MMCache, it almost makes templating a moot point if you cache
the heavy things correctly. For instance, on a site I made, I have
roughly 10 join queries on the front page. I use Turck to cache the
processed query results in shared memory (although you don't need to
use turck, it provides a really simple interface) for five minutes,
and that way, when 1000 people hit my page in 5 minutes I'm doing 10
queries/template calls instead of 10,000.

Something that I've been playing with recently is XDebug (
http://www.xdebug.com/ ), it's pretty useful for code profiling and it
lets you know pretty quick where your slowdowns are.


On Wed, 19 May 2004 13:26:30 -0400, Steven Samuel <steven at sohh.com> wrote:
> 
> I'm not super techincal when it comes to installing applications on my
> Linux server. I'm co-located at Rackspace, and they do a good job of
> installing programs when I need it at $75 per hour. The one thing that I
> didn't like about Smarty was the installation, which is why I haven't
> used it yet.
> 
> Right now, I use phpLib's phpCache v1.4 - PHP caching engine. I just
> uploaded the templating file and that's it. Any page I want to use the
> template on, I just call it via the include and call the object.
> 
> Right now, I'd like to get more into XSLT and see if this would be
> better.
> 
> Steven
> 
> 
> 
> -----Original Message-----
> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
> On Behalf Of David Sklar
> Sent: Wednesday, May 19, 2004 9:32 AM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] Smarty
> 
> > Just read David Sklar's  "Essential PHP tools". It serves as a great
> > reference for Pear DB, Auth,HTML_Quickform etc.. I don't even know
> him,
> > so I'm not being biased.
> 
> Thanks!
> 
> > But I was curious about people's feelings of Smarty. Do most think
> > this
> > extra processing is worth it? A conscientious job of keeping logic and
> 
> > presentation separate would accomplish this as well. Any feelings?
> 
> I think Smarty is a helper in that "conscientiousness" department. If
> that help, for your project or company or whatever, is worth the
> performance tradeoff, then Smarty is a good idea.
> 
> There are plenty of ways to boost Smarty's performance (caching, using
> an accelerator), so you can minimize the performance hit. And, to be
> completely honest, most web sites aren't running at the level where
> every last bit of performance is so crucial.
> 
> A legitimate downside to Smarty is that you need to learn, essentially,
> another programming language -- Smarty's syntax for variable
> interpolation, its function names, etc. But if that syntax is easier to
> grok for your site designers, then that's a good thing.
> 
> See also Adam's spot-on mini-rant a little while ago about including
> human time spent and programmer convenience in your calculations of cost
> 
> and performance. Smarty's advantages definitely fit into that category.
> 
> > Also, any feelings about DB and whether there is a big performance
> > hit?
> > Also, does it work well with stored procedures and other RBDMS
> specific
> > goodies?
> 
> I think the big win of DB is that it provides a unified API for database
> 
> access, not so much that it abstracts SQL features whose implementations
> 
> vary across databases. Whatever database program you're using,
> DB::query() sends a query off to the database and (perhaps) returns a
> result handle. The contents of that query can be standard SQL,
> vendor-specific SQL, a stored procedure, whatever you want.
> 
> David
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org http://lists.nyphp.org/mailman/listinfo/talk
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>