Nathan Rixham wrote:
In your application itself, caching can be introduced at every level, you've already got filesystem io caches provided by the operating system, a well tuned db server cache can make a big difference as well, then on to opcode caches in languages like PHP since it's interpreted rather than compiled, and then on to code optimizations such as using static class cache's behind getByID methods and similar, and finally down to micro optimizations, static code analysis and dead code elimination, replacing (4*10) with (40), inlining static class members / constants and such like. Finally, language specific nuances and micro optimizations.
Actually THAT probably sums things up nicely. An approach suitable for MySQL WILL probably be wrong for Postgres or Firebird. Certainly the optimised SQL I use for my own applications is much improved if I simply ignore compatibility with the databases other developers are using. Libraries like doctrine and even PDO are probably not using the best approach that a database specific approch may take. Firebird will maintain the 'results' of previous searches in cache and give results sets a lot faster, such as being ready to return the next page of results BEFORE the web page asks for it ;) But a database agnostic approach is not as efficient.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
