SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 61
  1. #26
    SitePoint Member Anachrony's Avatar
    Join Date
    Jun 2004
    Location
    Santa Barbara, CA
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That was a very helpful response, lastcraft. There was one thing I didn't understand though. I thought "content-length" was a pretty standard element of headers, so how can the web server spit out the first 2k before it has completed generating a dynamic page? I've been playing with a simple web server that I wrote (to help me understand the fundamentals of web transactions), but it always has to finish generating a page before it can send out the header, due to this content-length issue. Is content-length optional? Do dynamic pages often omit it?

    Also, for as stylesheets causings seconds of delay, shouldn't that only happen on the first page? If your pages share a small set of stylesheets in common, after the first page is accessed, shouldn't the user's browser have them cached locally and instantly available as the user browses your site?

  2. #27
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ruud

    McGruff - are the only options available OOP vs. spaghetti code?

    Ruud
    That was taking things to extremes for the sake of an amusing (well I tried..) story.

    However, I think it is true to say that the aim of writing well-organised, modular code where all the different threads are nicely separated does lead you inevitably to OOP. I think this is really the primary goal. There are so many other things likely to have a noticable impact on performance (did the designer go nuts on graphics eg?) and, in my own limited experience, OOP designs will not slow things down. You might say OOP promotes optimisation, if it's necessary, by virtue of a more easily testable, update-able design.

  3. #28
    SitePoint Evangelist Fleeters's Avatar
    Join Date
    Jul 2003
    Location
    Dumpsville
    Posts
    406
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I didn't read any of the above I just want to say what I have realized performance wise.

    I used to put all related functions in one file. But, Why do that? For each page your using a different function.. (forms, processing, etc). So you have to include that whole file and not use all of it. I started writing scripts like this: I code one main file with a switch statement. then depending on a variable you choose which scripts to include. I seperate the seperate scripts up kind of like how functions work but in files.. It DOES run much faster. because you dont include that whole include file with all those functions that are not all being used on one page.

    I just started doing that and there is a huge performance difference.
    Aaron Smith
    smithaaronlee.net

  4. #29
    SitePoint Member
    Join Date
    Jun 2004
    Location
    Canada
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff, I fully suspect your right. The thrill and excitement I felt when I discovered PHP (I love coding: work is fun!) is rivaled but my discovery of OOP. As with PHP itself, you can step in at just about any level and take it from there. It truly is a thing of beauty.


    Aaron, I did a smiliar thing recently with a script. Works very nice and clean.

    Ruud

  5. #30
    does not play well with others frezno's Avatar
    Join Date
    Jan 2003
    Location
    Munich, Germany
    Posts
    1,391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored into lean & mean classes by Mr Oop.
    i like that one

    The moral of the story: php is very fast. It's actually very difficult to write a "slow" script. Programming is much more about writing literate code which a person can read and work with easily than it is about making computers do stuff.
    i definitly aggree
    PHP is fast and humans usually don't realize a difference of 0.05 ms or 0.1ms etc.
    Bottlenecks in the code are pretty often loops and db-queries (or worse: queries within a loop).
    That would be a good place for looking for improvement and optimization.
    Also displaying graphics can take an (feeled) eternity to load. How many user quit while waiting for a page to build up?
    IMHO especially there, there's room for improvement.

    I personally don't look for getting the very last ms out of my source but stay with those obvious issues.
    We are the Borg. Resistance is futile. Prepare to be assimilated.
    I'm Pentium of Borg.Division is futile.Prepare to be approximated.

  6. #31
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    France
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Anachrony
    I thought "content-length" was a pretty standard element of headers, so how can the web server spit out the first 2k before it has completed generating a dynamic page? I've been playing with a simple web server that I wrote (to help me understand the fundamentals of web transactions), but it always has to finish generating a page before it can send out the header, due to this content-length issue. Is content-length optional? Do dynamic pages often omit it?
    Content-length is optional, and most dynamic web sites do not send it. For the reason you found out - you cannot send it until the output generation is finished. By default your PHP scripts will not send it either.

  7. #32
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    France
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Most of the "tricks" I've seen to speed up PHP code will yield ridiculously low gains in speed. We are talking about CPU cycles here, not even ms.

    When your database takes 200 ms (or 2s !) to run a query, shaving off 1 ms on "optimized" (but hard to maintain) PHP code is absolutely ridiculous.

  8. #33
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ruud
    McGruff, I fully suspect your right. The thrill and excitement I felt when I discovered PHP (I love coding: work is fun!) is rivaled but my discovery of OOP. As with PHP itself, you can step in at just about any level and take it from there. It truly is a thing of beauty.

    Ruud
    I know what you mean. My own epiphany moment arrived when I first came across Eclipse.

    Well, not exactly when I first came across it but when I finally understood it.

  9. #34
    does not play well with others frezno's Avatar
    Join Date
    Jan 2003
    Location
    Munich, Germany
    Posts
    1,391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    [...] Eclipse.
    Well, not exactly when I first came across it but when I finally understood it.
    Lucky you, i'm still far away from understanding it...
    We are the Borg. Resistance is futile. Prepare to be assimilated.
    I'm Pentium of Borg.Division is futile.Prepare to be approximated.

  10. #35
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ization
    Quote Originally Posted by Betcour
    Most of the "tricks" I've seen to speed up PHP code will yield ridiculously low gains in speed. We are talking about CPU cycles here, not even ms.

    When your database takes 200 ms (or 2s !) to run a query, shaving off 1 ms on "optimized" (but hard to maintain) PHP code is absolutely ridiculous.
    This is (one of the) smartest comments in this thread so far. Everybody should now that Premature Optimization does a lot more harm, than good.

    The efficient way to optimize code, is with a good Profiler (e.g. XDebug for PHP).

  11. #36
    does not play well with others frezno's Avatar
    Join Date
    Jan 2003
    Location
    Munich, Germany
    Posts
    1,391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    q.e.d.
    We are the Borg. Resistance is futile. Prepare to be assimilated.
    I'm Pentium of Borg.Division is futile.Prepare to be approximated.

  12. #37
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but Mr Spaghetti is very proud of a 0.02s speed advantage
    yes but the 0.02s is only part of the story , the extra procesing time requires extra CPU & extra RAM (which unlike disk-space still is a consideration) , with a busy site multiply that by any number that comes into your head (on shared servers multipy that by another hundred or so)

    .. the original question was (I assume) talking from a pure PHP at the server level , all the points that Marcus notes are interesting and insightful , but regardless of those issues ... should we still not want our code to be optimal in both performace & resource usage as well as maintainable ?

    Its like saying ` well the brakes are not very good on the car but the roads are so bad you can't go fast enough to need them anyway.. so dont worry about it`

    I worry especially with the new OOP features available in PHP5, that performace issues are far too often `thrown away` as an issue , often with examples like the spaghetti one above (which is of course in itself valid)

    are the only options available OOP vs. spaghetti code?
    far from it , I have OOP that creates spaghetti code for me , its a tradeoff , functions / procedural code is noticibly faster than OOP alternatives (especially under load) but OOP is easier to maintain , so I have come to the point of creating classes that create procedural code (the trick is to not be tempted to change that output directly but fix you classes so the output is right).

    The biggest `disadvantage` thrown at PHP is that it is not compiled .. I personally see this as an advantage , but accepting that comes means accepting the fact that PHP is interpreted , and interpreted languages require handling appropriately , overheads of database abstraction , page objects creating simple HTML etc need to be considered and not simply ignored unimportant when compared to code reusability because they are , they should go hand-in-hand.

    I am petty I use ++$var instead of $var++ , but for how hard it is to employ .. why wouldn't I ?

  13. #38
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by firepages
    Its like saying ` well the brakes are not very good on the car but the roads are so bad you can't go fast enough to need them anyway.. so dont worry about it`
    No it's more like saying take that extra 5 kilo out of the trunk so your braking distance will reduce, when the effect of that is ver small. But at the same time you could do a detailed checkup and find that the profile of your tires is down to 2 Millimeters, or you lost half of your breaking fluid.
    There is (almost) always a better fix-up for performance than those "little tipps" that are given. Hence my Link to http://www.google.com/search?q=premature+optimization

    When you profile first, and then take care of the slow passages you can (almost) always make more improvement, than if you start writing ugly code in the hopes that it will be faster.

    It's 20% of the code that's responsible for consumption of 80% of the resources. There is no value in "optimzing" the other 80% of the code. Just focus on what is (factually) slowing down your individual scripts.

    And even if your scripts are so trivial, that the 80/20 rule wouldn't apply, you can still speed up your scripts a lot better with proper caching-techniques, rather than with those "little tips".

    The biggest `disadvantage` thrown at PHP is that it is not compiled .. I personally see this as an advantage , but accepting that comes means accepting the fact that PHP is interpreted , and interpreted languages require handling appropriately , overheads of database abstraction , page objects creating simple HTML etc need to be considered and not simply ignored unimportant when compared to code reusability because they are , they should go hand-in-hand.
    There are Encoders/Byte-Caches available for PHP from Zend, from Turcksoft(sf.net) and others. If you need it to be compiled, you can do it.

  14. #39
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can see that premature optimization may have its downfalls , I won't argue that , but that does that mean `don't optimize` ? I hope not,

    compilers & byte-caches are not the point , only page caches ignore all resource issues.

  15. #40
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd say to script for easy maintenance over and above performance any day of the week

    It's the 21st Century for crying out loud, the technology exists and it's getting more powerful every quarter so sod it

    Us developers have enough to do as it is, with development time shortfalls being a big issue. Like I've not had one client yet to phone or page me complaining about performance issues, so what's the big deal huh ?

  16. #41
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Ruud
    I guess that...in the end pure script speed does matter.
    Why guess? Optimisation is just about the only part of "software engineering" that is actually engineering.

    No one on this thread seems to want to do any calculations, so I'll have a go. This is only for server load (the less important factor) on an imaginary busy site...

    Say we have five web servers and two MySQL servers (one doing replication). Every page makes a request to MySQL to get the session information, and about 25% of requests are to fetch business data. Say the web servers are 1U 1GHz boxes with IDE drives and a half gig. of RAM, whilst the DB servers are 2U twin 1GHz with RAID SCSI and 4 gig of RAM.

    A quick look around for prices and we find that the web servers will cost each month (for Linux) about $300 apiece, the data servers about $800, the load balancer and firewall $400. Total $3500 per month.

    We issue the following command whilst logged in to one of the web servers...
    Code:
    time wget localhost
    ...and get...
    Code:
    --12:11:28--  http://localhost/
               => `index.html.4'
    Resolving localhost... done.
    Connecting to localhost[127.0.0.1]:80... connected.
    HTTP request sent, awaiting response... 302 Found
    Location: http://localhost [following]
    --12:11:28--  http://localhost/
               => `index.html?ct=1'
    Connecting to localhost[127.0.0.1]:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [text/html]
    
        [     <=>                                                                                           ] 32,960        37.00K/s             
    
    12:11:30 (37.00 KB/s) - `index.html' saved [32960]
    
    0.02user 0.01system 0:01.76elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (411major+106minor)pagefaults 0swaps
    The only part we are interested in at the moment is that "0:01.76elapsed" as the other loads are to do with our client request.

    Next, you want to run "top" on your server to find the load. If any part of your load at peak times get to 85% then performance will decline noticeably. Things start to queue up and "choke" the server. Below 60% load your servers are working at full speed and have reserve capacity. Even if a server dies, the site will carry on as normal. optimisation is a waste of time when you have capacity unless you are hoping to decomission a server.

    Now, the worst case scenario. We are running about 85% load at peak times and people are noticing when things are busy. That 1.76 seconds will not really be noticed on the remote browser, but this is likely an average - you may get pages that take 5 seconds and that certainly will. To restore normality we need an extra 20% capacity, but let's get some room for growth and go for 50%.

    We now make a query to the DB server (insde the Unix "time" command again) and find that it is taking 0.8 seconds as well. This is way too slow and a look at the server load confirms we are running 100% and the replication is falling behind at peak times. We are using the rep. server as backup, so that means our back up is out of date at peak times. This gets worse and worse .

    A quick calculation comparing the session query with others (at off peak times ) shows that sessions eat up about 40% of the load and running queries from the DB severs themselves (via. localhost) saves another 30%. The business queries are read only, but the sessions are complicated.

    Looks like everything is bad. OK, what's our strategy?

    We could rewrite all of our scripts. If it took 6 months to build the site with four developers, it will probabaly take at least a month rewriting any bottlenecks. Say the code is stable and it has a churn of six months. Four developers working for a month is $25000, so that is about $4000 a month average. Developers come and go and the current people have to figure out the extended code when they add stuff. We are lucky if this only doubles the cost - let's say $8000 per month. You will be extremely lucky if you can squeeze even 25% improvement in efficiency from this process anyway. You could double your server count and still save money compared to this madness.

    Let's try something a little more sane. Let's enable the session tracking option in out load balancer. Assuming that the session storage driver is about 200 lines of code we could rewrite it in a few days if it happens to conflict with the balancer. Upgrade the balancer if it doesn't have this facility. Cost about $1000, but this is a one off.

    Now that a sessioned user always comes back to the same server, we can place the sessions on the web servers. That takes a substantial load (probably about 55%) off of that loaded DB server. It will also speed up the web servers because they will be making localhost calls to their own databases. The downside of course is that there is now even more load on the web servers.

    The DB server load is still a little high, but we would have to spread it's business data over several servers to improve this. This will involve some code changes as well and so will likely be expensive. Let's do cheap things instead. We'll change the CPU's to 2Ghz and switch the network to 1GHz ethernet with as much intelligence on the card as we can buy. Probably a one off $2500 altogether not counting administration time as you juggle servers during upgrades. Add a sysadmin spending a week on this at $1000.

    Back to the web servers. Either we ugprade them or add more. Upgrading is cheaper, but let's assume they are maxed out. We could add five more and nearly double our capacity. We could get by with less if we rewrite the sessions to use DBM or SQLite and this is more effective. Let's guess at two extra servers and a developer/week rewriting the session management and porting the old sessions ($1500 one off). We could add Zend accelerator licences at $2000 a year per box ($166 per server month). It sounds like we would get a good boost from this (probably more than 200% for simple pages).

    Total cost is $6000 one off plus $1766 per month. This will easily buy us 50% more load, probably 100%+.

    Quote Originally Posted by Ruud
    On that note - OOP in PHP is said to be a tad slower then using function.
    A note on personal optimisation of your own time. The time spent finding and reading junk like this could be better spent learning how HTTP servers do caching, or finding out how much servers cost or researching ways to do development faster. Code twiddling is a complete and utter waste of time.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  17. #42
    SitePoint Member
    Join Date
    Jun 2004
    Location
    Canada
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Firepages has put it better than I have so far.

    Take Yahoo for example. I know that for every new feature they think about they look at speed and load. They do calculate down to the microsecond. If the new feature is a ms too long they will not implement it until they can get it within the range they want.

    What I do get from this thread is the notion that optimising code for (server) speed is considered to be equal to messy, hard to maintain code. I don't understand why the two would be equal yet.If using single quotes vs. double quotes has a slight advantage, if using ++$var has a slight advantage over $var++ ... how does that make code hard to read/maintain? If I would give two SQL queries which could easily be combined into one I don't think readability or maintenance would be an issue.

    I lean towards the idea that writing the best code from the start is better than expecting large companies to deliver me extra hardware or for shared hosts to expand their server farm.

    Including files does seem to be a process which can take considerably longer than the 0.02ms we can safe on optimised code. That it is not an issue at all to many is something I fail to understand so far simply because from what I have heard from larger companies - performance is an issue.

    And, as I said, that optimised code is equal to time waste and messy code.... I had no idea.

    Ruud

  18. #43
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Sorry to use your quote in the last reply, Ruud . I wasn't aiming the comments at you by any means, only net "articles" that say a method call is twice as slow as a function call or whatever.

    Quote Originally Posted by Ruud
    Including files does seem to be a process which can take considerably longer than the 0.02ms we can safe on optimised code. That it is not an issue at all to many is something I fail to understand so far simply because from what I have heard from larger companies - performance is an issue.
    I don't want to leave anyone with the impression that optimisation isn't important, it is. In fact I work with just this kind of system. There is a difference in optimisation and code twiddling, though.

    Worrying about double or single quotes on SQL queries is definitely in the twiddling category. Any time saved will be swamped my network and disk access. Optimising that query for the DB server on the other hand will likely have a payback if your DB server is bottlenecked (which is common in PHP systems). The caveat is to measure it first. If it's not the bottleneck, you gain nothing.

    Optimisation almost always does damage to the code base in practice. We actually measure development time as part of our processes and optimisation does cost us a factor of 3-5 in development time. Think about things like caching, code generation and lazy loading for example. It takes much longer to build high performance systems than people typically think.

    I spent two months last year optimising queries to a full text engine (our queries typically took 10+ seconds). Full text tends to be full of obscure text matching rules anyway, but the result was code that is now unmanageable (although down to 2 seconds). We just don't want to touch it anymore. Recently we wanted to add some new features and figured in the cost of refactoring this code after adding them directly. Too expensive was the conclusion and so implemented the feature as a post processing on the current results. This took longer than just adding the feature directly without optimisation. This also complicates the code more in turn. Now we chose to accept the huge code hit on this one and that's what I mean by an ROI calculation. You cannot do that calculation without hard figures.

    Don't guess.

    yours, Marcus.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  19. #44
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My personal view ?

    Throw another couple of servers at it

  20. #45
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Widow Maker
    Throw another couple of servers at it
    We would have done if we could. This isn't a load issue though, but a response time issue, so it doesn't help .

    We have found a way out of our dilemma for the future though. We are outsourcing an open source alternative that is specific to our needs. That way we can replace the entire subsystem that we were pushing too close to it's limit.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #46
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's the 21st Century for crying out loud, the technology exists and it's getting more powerful every quarter so sod it
    ... & thats been JAVA's argument for how long perhaps one day it will work out for them.

    Worrying about double or single quotes on SQL queries is definitely in the twiddling category.
    twiddling for sure , how hard to implement ?

    put it this way , ignore the millseconds side of the argument ..

    if routine a is is 100% faster than routine b , and where its not rocket science to work out or implement such ... ok even if its only 50% faster, ok 25% .. why would you not do it ?

    what other (non-govermental) trade can you enter where such disregard for resources (however small) would get you anything else but the boot ?

    Take into account that in a given codebase such operations may be called hundreds of thousands of times ... I can not see how it is acceptable to ignore that waiting for mod_magic to fix it for you.

    I do not suggest rewriting the logic of an application to save a few millseconds simply that if you are aware of the issues before you start then things can only get better from that point.

    too often in this forum perfectly valid the 'is this more efficient way ' questions are brushed aside with 'get a faster CPU' answers.

    again points about page/server caches are another (important) consideration perhaps moreso in the greater scheme of things , but they need to be considered outside of other possible issues.

  22. #47
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    put it this way , ignore the millseconds side of the argument ..

    if routine a is is 100% faster than routine b , and where its not rocket science to work out or implement such ... ok even if its only 50% faster, ok 25% .. why would you not do it ?
    Because 50% of bugger all is still bugger all.

    In your car example, what would you think about knocking off the door handles to reduce drag and thus make the car go faster?

    Programming isn't just about making computers do stuff. It's much more about creating code that people can read and work with easily.

  23. #48
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "what would you think about knocking off the door handles to reduce drag and thus make the car go faster?"

    Perhaps if Jensen Button had done that to his BAR on Sunday he would have done better...

    Of course if you are driving your tractor to the market , probably not.

    depends what your goals are.

  24. #49
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Please excuse the forthright language. It's just that I feel that being over-concerned with optimisation details which don't produce any significant gains is a common mistake which impedes progress towards the goal of learning to produce well-designed programs.

  25. #50
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by firepages
    ... & thats been JAVA's argument for how long perhaps one day it will work out for them.
    Java is way fast enough, even on my mobile phone. You wouldn't want to go the J2EE route unless you have a specific scaling need for it though. As one of the most successful development languages of all time...well let's just hope it works out for them soon .

    Quote Originally Posted by firepages
    if routine a is is 100% faster than routine b , and where its not rocket science to work out or implement such ... ok even if its only 50% faster, ok 25% .. why would you not do it ?
    Because it is a waste of developer time.

    Your "percentage" is bogus. A one miliseconds worth of code that has a 100% improvement is now half a milisecond. A DB query will take 20-50 miliseconds even on localhost.

    Why don't you try measuring the impact of such an "optimisation". Time one of your "optimised" pages. Start the clock ticking and de-optimise it by changing the quoting rules. Now measure it again. Then do the ROI calculation and tell us about the money you just saved.

    You are describing the problems in terms of fear. Phrases like "hundreds and thousands of times" is hand waving at best. Can you find such a statement in your code? If you do you would be better advised to find a way to remove the entire 100,000 iteration loop and replace it with something more efficient.

    Quote Originally Posted by firepages
    I do not suggest rewriting the logic of an application to save a few millseconds simply that if you are aware of the issues before you start then things can only get better from that point.
    So what awareness of the issues could cause me to spend several days changing SQL quoting in order to get a speed improvement I cannot even measure?

    Quote Originally Posted by firepages
    too often in this forum perfectly valid the 'is this more efficient way ' questions are brushed aside with 'get a faster CPU' answers.
    That is not the case here and not what I am saying with "twiddling". There is a bit of a syndrome with optimisation in PHP...
    1) Script kiddie learns PHP.
    2) Script kiddie gets blog.
    3) Script kiddie learns to use a profiler (wow).
    4) Script kiddie measures a couple of isolated functions in a loop.
    5) Script kiddie posts "article" with lot's of scientific looking tables.

    I have spent ten of my last twelve months doing almost nothing but optimisation. We now routinely do fuzzy full text searches on 10gig data sets in two seconds or less. We frequently make 3-4000 page fetches a minute from a single spider running on a single server. How?

    We precalculate and denormalise selected text data. We parallelise page and XML fetching. We tune DB queries to avoid backtracking and linear table scans. We create presorted and preordered data sets. We measure performance of DB keys. We distribute HTTP load over proxies. We cache results (a lot). We move network traffic around in large portions on fast network cards. We use framed pages to avoid reloading data in side by side comparisons. We give plenty of specialist search areas in the site so that people get the data they need with the smalles number of requests. We place DB indexes on RAM disks. We write special sections of code in C. We spread the load over multiple servers.

    The only time a PHP code level profiler has given us a useful improvement is when we saw a large number of fread() calls jamming up the disk after about 200 file handles had been opened. By fetching the content in one big slurp the SCSI RAID system was better able to optimise the disk access for us, giving us 20% (on an already highly optimised system). Nothing else gave us more than 2-3% in the PHP part of the code (which is usually only about 10% of the total script time and barely a third of the load). We did not in fact make those code changes because the developer cost would dwarf the hardware upgrade costs.

    All the other techniques have lead to order of magnitude improvements and have only been possible because we have kept the code base flexible.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •