SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    $books++ == true matsko's Avatar
    Join Date
    Sep 2004
    Location
    Toronto
    Posts
    795
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Does Code Packing Optimization Work?

    I am not sure of a name for it, so I just refer to it as code packing. The optimization part is the idea that it could speed up execution time...

    I tried using a PHP code optimizing program which practically stripped off all my comments and spaces, and packed all the code into a simple 1 line file. The program worked just as it did before, but I didn't really see too much of a difference... The page was setup with a microtime() start and end evaluation to determine the total execution time and here are the results...

    I noticed that without the optimized php file the execution time fluctuates more. It can execute faster and it slower. With the Optimized php file thou I noticed that it had a steady execution time throughout. Although it didn't really do much at all to improve the speed ( the website is still in development ), but it did give me an idea about code optimization.

    My persumption about this is that a high traffic website could be a little more stable with optimized code (once again: stripeed comments, spaces, and everything crunched into one line)...

    What do you guys think?
    I can't believe I ate the whole thing

  2. #2
    SitePoint Wizard HarryR's Avatar
    Join Date
    Dec 2004
    Location
    London, UK
    Posts
    1,376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,
    Simply stripping all comments and whitespace from the code itn't going to do much to help speed it up, and the only real benifit that I can see behind this is saving perhaps a millisecond or two that PHP takes to parse it. Not only that but if an error crops up at runtime it becomes a guessing game as to where it is in the original source file.

    If you really want to save some time, use a bytecode cache like eAccelerator, ionCube or Zend's Performance Suite, or simply compile them for use with one of the many loaders out there (Zend Optimizer, ionCube loaded etc. etc.).

    At the end of the day the time it spends loading the PHP files is inconsequential compared to what a rogue query or badly designed database can do to slow everything down.

    Ta - Harry

  3. #3
    is_empty(2); foofoonet's Avatar
    Join Date
    Mar 2006
    Posts
    1,000
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Optimised code: http://www.ipersec.com/index.php?q=en/bench_ea_vs_apc
    Quote Originally Posted by ipersec.com
    benchmarking comparisons and explanations.
    Executing a PHP scripts takes a few steps :

    1. PHP loads the file,
    2. it parses the source file, and transforms it into opcodes (code that can be executed by the server),
    3. it executes the opcodes.

    The accelerator takes the opcodes from step 2 and caches them in shared memory or on disk. Those cached opcodes are then directly reused the next time the PHP file is executed, without loading & parsing the file again.

    Some accelerators add an optimization step which removes unnecessary code (empty loops, unused variables, ...). In most cases, this optimisation step does not improve performance much...
    If you are using 5.1.x you can enable apc www.php.net/apc

    That might be useful if your code packing means opcode, and opcode cacheing will do what you want. I find it truly fascinating the files that it caches, using the recommended apc.php script. It tends to cache all the frequently used include files. Only used it for a few weeks and havent honestly tried tweaking it yet. Judging by the amount of times some of the files are requested I think it may help me identify some bottlenecks I have.

    Good luck

  4. #4
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wouldn't be doing the code packing. Modifying the code is going to be a pain and I can't see the speed improvements overcoming the maintability issues.

    Probably better of analysing your code for other ways to optimize. Is performance an issue for you anyway? Is the code running slowly?

  5. #5
    Mlle. Ledoyen silver trophy seanf's Avatar
    Join Date
    Jan 2001
    Location
    UK
    Posts
    7,168
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by matsko
    What do you guys think?
    Thinking of ways to save a few milliseconds processing time is pointless, as it will make no noticeable difference. Don't worry about the performance of your PHP code at this stage, just get it into production and see how it runs. If you find some areas are lagging then you can start investigating performance issues. You will most likely find your code runs along quite nicely.

    However, you should always optimise your SQL queries (think carefully before using subquerys, always implement and test indexes, etc.), as this it what will make the real difference in web applications. Any other performance issues can be solved with hardware upgrades.

    Sean
    Harry Potter

    -- You lived inside my world so softly
    -- Protected only by the kindness of your nature

  6. #6
    $books++ == true matsko's Avatar
    Join Date
    Sep 2004
    Location
    Toronto
    Posts
    795
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So for the opcodes idea that was mentioned I guess you can say that its a compiled stage of the php source code.

    So what you are saying is that when the php file is accessed, the "Compiled" file is cached and is used instead of parsing the original file...

    Is there any way to just have your php script pre-compiled and ready on the server? or is that just a bogus idea...
    I can't believe I ate the whole thing

  7. #7
    is_empty(2); foofoonet's Avatar
    Join Date
    Mar 2006
    Posts
    1,000
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you can add it to the apc cache "manually", havent checked this out yet. ditto I think you can delete things from the cache, you can with apc.php so I guess its a matter of learning the call.
    Upgrading to Mysql 5? Auto-increment fields now strict
    use NULL
    Or zero or leave the field name out completely.

  8. #8
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Simply stripping all comments and whitespace from the code itn't going to do much to help speed it up, and the only real benifit that I can see behind this is saving perhaps a millisecond or two that PHP takes to parse it.
    Also, using microtime() to benchmark doesn't take into account the time saved in the parsing stage, since microtime() only executes after the script has been parsed.

  9. #9
    SitePoint Wizard bronze trophy Immerse's Avatar
    Join Date
    Mar 2006
    Location
    Netherlands
    Posts
    1,661
    Mentioned
    7 Post(s)
    Tagged
    1 Thread(s)
    Sort of. Using Zend and IonCube type encoders will create a sort of intermediate format, halfway between 'raw' PHP code and op-code. PLus your users won't be able to read your code, if that's what your after.

    However, these types of opcode caches do require runtime extensions to PHP to work.

  10. #10
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like blank lines. They make code much, much better.

  11. #11
    $books++ == true matsko's Avatar
    Join Date
    Sep 2004
    Location
    Toronto
    Posts
    795
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah I practically do all of my coding with lots of comments and then when the script is flawless I pack all of my files and then upload them. Although I dont really get any extra speed out of it I still get to have detailed scripts with lots of comments and then have a some what optimized scipt up on the website.
    I can't believe I ate the whole thing

  12. #12
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    London
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I hope that you did not pay for your "optimisation" program!

    The easiest and relatively painless way to get a possibly big performance gain is to use a compiled code cache. EA, our new IPS system when released, ZPS etc. are all good examples, and can reduce total request time by 4 or 5 times in many cases. Depending on the code execution time, this may be less, but may be even more. This speedup comes from caching and executing code directly from shared memory, and reduces the cumulative time or processing before execution on a request from 10's or 100's of milliseconds to almost 0. In addition, code optimisation significantly reduces the compiled code size, and can also improve the execution performance.

    Just as installing a cache makes good sense, so does understanding your application and creating a good application architecture. Once you've installed a cache, if there is only a marginal improvement in performance then that in particular suggests inefficiencies elsewhere, either in the PHP coding itself, in the overall solution, or with the database usage, and quite possibly all three. If the application is heavily database oriented, then if you don't know what queries are performed on each request and how many, it's time to find out. Use the getmicrotime function to time queries, and log the queries made on each request.

    Do a code review (particularly if someone else wrote the code), and look at the amount of PHP code used to process the results of queries. If you have PHP code to post process the query results, and if you're performing multiple queries to complete a particular operation, there may be scope to dramatically improve the solution through better use of SQL. e.g. instead of doing two selects and then using PHP to find out which rows in one table do not have a corresponding row in the second table, learn how to do this with a left join. Become aware of the inbuilt database functions. Understand about table indices and when to use them and when not to use them. Use "explain" and analyse your system to discover if using straight join to force table ordering will improve performance (it can sometimes make a massive difference). If you have a chance, use query caching in mysql 4.

    There are other things to look at too, but lastly comes better hardware. Of course make sure that the hardware that you have already is configured well such as having DMA enabled for the drives, but after that consider more memory and a better processor. This shouldn't be used a crutch though, as there's no substitute for learning how to design and develop efficient and well crafted solutions in the first place.

  13. #13
    SitePoint Addict Clenard's Avatar
    Join Date
    Sep 2004
    Location
    USA
    Posts
    337
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    Also, using microtime() to benchmark doesn't take into account the time saved in the parsing stage, since microtime() only executes after the script has been parsed.
    yep!

  14. #14
    SitePoint Member
    Join Date
    Jun 2006
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig
    I like blank lines. They make code much, much better.
    Me To.

  15. #15
    SitePoint Wizard Pedro Monteiro's Avatar
    Join Date
    Sep 2002
    Location
    Lisbon
    Posts
    1,393
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The old spaghetti code! The way I see it, if you can save a millisecond of loading time, why not save it? And this is assuming that you wont save a lot more loading speed.

    I have been able to reduce 20K pages to 17K just by eliminating unnecessary line breaks and spaces.

  16. #16
    SitePoint Member
    Join Date
    Jun 2006
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    whitespace/redundant [?] code concerns

    Hi,

    Please excuse my ignorance. I am posting on this forum as a marketer with concerns for SEO performance, and not a developer.

    We currently operate a CMS driven ecommerce website , which on each and every page generates 80+ lines of white space followed by the developer's promotional spiel, THEN the doctype declaration, then a lot of meta head content which is now arguably redundant in SEO terms.

    I am just wondering if all white space etc can have an impact on site performance [in SEO terms as well as bandwidth etc], and if there is an industry standard <head> which should be subscribed to?

    thanks


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
  •