On Wed, Oct 20, 2010 at 3:18 PM, Tac Tacelosky <tacman@xxxxxxxxx> wrote: > "Premature optimization is the root of all evil." > http://en.wikipedia.org/wiki/Program_optimization > If you need to include a big library to do a task, and it's cached, so what? > ÂWhy are you trying to write fast code that doesn't need caching? ÂThat's > not necessarily sloppy code. ÂAnd sloppy code is often very fast. ÂHeck, > function calls are slower than cutting and pasting duplicate code. And a > class hierarchy has lots of "inefficiencies", but saving a few CPU cycles is > not a worthwhileÂtrade-offÂmost of the time. > IMHO, of course. > Tac > Hi Tac, All that remains for this phase of the project is make the classes to model the database accordingly and the UI (html, css, ajax, etc). So I doubt there's much optimization I can do about those (except for Javascript related). This project originally started with highest script execution of about 1sec and memory usage of about 1MB, without xdebug's profile. After completing the design to serve the purpose needed, I trimmed it down to ~210ms (most of that is from require/include, the actual script execution is less than 40ms). Memory consumption is about 800KB. So for now, I'm very satisfied except for that require/include varying times. I'll deal with it later since the core of the project's is within reason before other aspects (DB model, UI, etc) are built. My overall aim is to have the application response time of 3 seconds or less (from the time the user clicks on a link to the time when the web browser status is 'done') before caching is applied. So far, I think I'm on track. I'd give 750ms to 1 sec for the application to get all that's needed from the DB, and about max 750ms to process the data for output. That gives me about 1 sec of leeway :) Thanks, Tommy -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
