SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 59
  1. #26
    SitePoint Enthusiast
    Join Date
    Aug 2000
    Location
    Bay Area, CA; (Pasadena, CA this fall)
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I decided to do my own benchmarks w/ __autoload(), so that there is a hefty fee for parsing all classes and only parsing/including those classes when necessary.

    Time per request: 95.313 [ms] (mean) -evaling() all classes; http://newoop.com/typeCheck-127kb.phps (all classes in 1 file; 127 KB, ~2500 lines)
    Time per request: 120.156 [ms] (mean) -including() as needed; http://newoop.com/typeCheck.phps & http://newoop.com/Web%20app-6-22-04.zip

    http://newoop.com/benchmarks-6-22-04.txt


    It means that the IO time does still make a difference. This is on Win XP Pro+Apache 2+mySQL+turk mmCache+PHP5 RC3

  2. #27
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    __autoload() was added in PHP5, and it's pretty easy and nice to use 
    ...but is slower than traditional includes/requires which still are (next to image processing/system stuff) one of the biggest performance issues with larger PHP scripts.

    thanks Mr Jeep for sharing so we no longer have to worry about spending an afternoon or whatever creating such ... which is half the point of OSS for those who missed the point

    ...just think if we throw some more hardware at it it will be faster again, perhaps that wrong as well ?

    the only issue I see is for conditional includes and requires (a problem PEAR's bcompiler has as well) , e.g. ideally you dont want to compile them in if they aint used ?

  3. #28
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is it just me, or is all this talk of compiling completely irrelevant?

    His script isn't 'compiling' anything. It's taking the scripts from your development directory, stripping out comments, whitespace, etc..., and dumping it in the production environment.

    All it does is make it so the PHP parser doesn't have to wade through comments and empty lines when your page is accessed.

  4. #29
    SitePoint Zealot spybreak's Avatar
    Join Date
    Apr 2003
    Location
    Germany
    Posts
    151
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Viflux
    His script isn't 'compiling' anything. It's taking the scripts from your development directory, stripping out comments, whitespace, etc..., and dumping it in the production environment.
    title of this thread: Php "compiler" class (quoted)

    It does indeed speed up my applications. Every include takes anywhere from 1 to 20ms or even more. And it adds up. If php doesn't have to access extra files, it certainly speeds up the script.

  5. #30
    SitePoint Enthusiast
    Join Date
    Jun 2003
    Location
    Chicago
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    It might benefit even more from some new hardware.
    Not everyone has the benifit of a dedicated server. This little difference mounts up.... Say you have a page with 6 library includes. 50 people visit the page in a minute, so thats at least 6 * 50 = 300 I/O ops per a minute. Add another 50 for the page itself, and thats 350 a minute. With the compiler, its 100 I/O ops per a minute. Thats a very large reduction, and is worth the benefits. It's not like this really costs development time or anything; you just use your dev libraries and "compile" for the final release. Leave the dev dirs in incase someone wants to make modifications.

    I actually use something exactly like this

  6. #31
    SitePoint Enthusiast
    Join Date
    Aug 2000
    Location
    Bay Area, CA; (Pasadena, CA this fall)
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why am I the only here who is arguing that the parsing/processing time for a massive file might offset the gains from skipping IO time?
    For example, what if there is a page that only would need to include 3 files? Would the IO time for opening/reading those 3 files really be greater than the time needed to parse all files in the library?

    Alright, I have an idea for a more advanced "compiler":
    Eliminate all include statements and use __autoload()
    __autoload() should be implemented by including files when necessary and mainly recording which files need to include which other files

    Now we have ~ the information to output each file with only the necessary includes.

  7. #32
    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 Aesthetic-Theory
    Not everyone has the benifit of a dedicated server
    But anyone can upgrade to one - or to a better shared host.

    Quote Originally Posted by Aesthetic-Theory
    Thats a very large reduction, and is worth the benefits.
    It depends to a certain extent what you regard as a significant reduction. There would be no noticable difference between a script with 6 includes and a script with 2. Hubble space telescope territory, I think.

  8. #33
    SitePoint Zealot patrikG's Avatar
    Join Date
    Aug 2003
    Location
    Sussex, UK
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree that the performance increases only by fractions of a second - but: it does add up. The company I am currently working for are pretty much putting all the logic into Oracle procedures and functions (well, as much as possible with Oracle 8 (that is: without Java)) simply because the performance is much, much better. PHP or any serverside scripting language won't be able to compete with it. Yes, while throwing more RAM, faster CPU, HD with 16MB cache etc might help, it's not what's on a managers mind. Simply because something is beautifully coded doesn't mean it will last. Performance is the key and PHP has much ground to gain on that.

    I think your class is very useful, Mr Jeep, and it is a start, but unless PHP-developers start thinking about performance, PHP will always be just a plaything compared to pre-compiled languages.

  9. #34
    SitePoint Enthusiast
    Join Date
    Jun 2003
    Location
    Chicago
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    But anyone can upgrade to one - or to a better shared host.


    It depends to a certain extent what you regard as a significant reduction. There would be no noticable difference between a script with 6 includes and a script with 2. Hubble space telescope territory, I think.
    Clients can be limited by monetary issues. I think this script is useful because it doesn't really require any aditional work, it just provides the benefit.

    "Why am I the only here who is arguing that the parsing/processing time for a massive file might offset the gains from skipping IO time?"

    They are parsed either way, so I don't think that would matter.

  10. #35
    SitePoint Enthusiast
    Join Date
    Aug 2000
    Location
    Bay Area, CA; (Pasadena, CA this fall)
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aesthetic-Theory
    "Why am I the only here who is arguing that the parsing/processing time for a massive file might offset the gains from skipping IO time?"

    They are parsed either way, so I don't think that would matter.
    So it's assumed that all files in the library are needed for every page?

  11. #36
    Now with customized title Jump's Avatar
    Join Date
    Sep 2002
    Location
    The Restaurant at The End of The Universe
    Posts
    1,423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is very cool. Except it cut off the end of a function for me.
    PHP Code:
            function __url() { 
                Return (
    $this->server == 'US')? 'http://subdir.sitea.com' 'http://subdir.siteb.com';
            } 
    Was truncated to.
    PHP Code:
            function __url() { 
                Return (
    $this->server == 'US')? 'http:
            } 
    which of course, resulted in an error.

  12. #37
    SitePoint Enthusiast
    Join Date
    Jun 2003
    Location
    Chicago
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webhappy
    So it's assumed that all files in the library are needed for every page?
    For me, I have a set of files that are needed every page. Others I include seperately, but its still a performance increase.

    IE, I always need

    database, template, log, error, auth, session/memory, and a generic function file.

    I may need the private message class, or the posting class, or an admin class.

    I compile the first group and include from the second as nescessary.

  13. #38
    Now with customized title Jump's Avatar
    Join Date
    Sep 2002
    Location
    The Restaurant at The End of The Universe
    Posts
    1,423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I added a check for url into the compile() function and it seems to not look at url's as comments now. But it would leave any comments that have urls in them I guess.
    PHP Code:
        // Remove end of line comments
                    
    foreach ($filelines as $i => $line)
                    {
                        if(
    strpos($filelines[$i], 'http://') === false) { //added url check
                            
    $filelines[$i] = trim($filelines[$i]);
                            
    $filelines[$i] = preg_replace('/\/\/.*$/m'''$line);
                        }
                        
                        
                        if (
    $i 10 == 0)
                        {
                            echo 
    '.';
                        }
                    } 

  14. #39
    Now with customized title Jump's Avatar
    Join Date
    Sep 2002
    Location
    The Restaurant at The End of The Universe
    Posts
    1,423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Anyway, thanks for this script. I never would have thought of doing this, yet it is a real time saver. Now I can work on scripts in there own files and just click a button to update the include file. Really cool indeed.

  15. #40
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm rather mystified at the number of people who claim to be obtaining significant performance gains. Maybe you could post some test results?

  16. #41
    Now with customized title Jump's Avatar
    Join Date
    Sep 2002
    Location
    The Restaurant at The End of The Universe
    Posts
    1,423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I'm rather mystified at the number of people who claim to be obtaining significant performance gains. Maybe you could post some test results?
    Well let's see here.

    I always put all my classes in a single file to have one include. I usually copy/paste them from their respective files into the target file. Then when I need to update them, I have to copy paste them again. Lot's of time wasted there.

    Now I just do what I have to do to the scripts in their respective files and just run the script and there it is, all done for me. Not much effort or time wasted there.

    Also, since the single files still exist, if I realy only need a couple classes I can still just include them.

    So overall, I would have to say that there are significant gains to my performance and much more time left to drink beer.

  17. #42
    SitePoint Enthusiast
    Join Date
    Aug 2000
    Location
    Bay Area, CA; (Pasadena, CA this fall)
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wonder what the gains are for skipping the comments. Unless some people really comment extensively, the tokenizing stage should not be that slow. If it weren't for the processing to strip comments/whitespace, this would be a pretty easy project.

  18. #43
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    VA, USA
    Posts
    57
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webhappy
    I wonder what the gains are for skipping the comments. Unless some people really comment extensively, the tokenizing stage should not be that slow. If it weren't for the processing to strip comments/whitespace, this would be a pretty easy project.
    Yes, from benchmarks I've seen removing whitespace & comments provides no noticeable performance increase. It wouldn't be hard to write a quick script to test it ... but I'm lazy

    Anyway, I prefer to have the comments; if I have to look at live code I want to be able to read it.

    In general, I/O can add up when including many files, but there are a couple of things to bear in mind:

    - most operating systems cache file loads in RAM, so subsequent loads of those files (e.g. by other scripts) should be faster. For example, I have attempted to improve site performance by running from a RAM disk, but it made negligible difference on a site that loaded many dozens (probably often > 100) files per request. What happens if you run that benchmark script a number of times in succession?

    - the bottleneck is always the database. At least in my experience, profiling a slow page will always point a big finger at the database connections and queries. Sure it's true that by putting the files in one class mr_jeep has improved the loading time by 2.x %, but the % doesn't really matter in this case because if your page takes 1.1 seconds to load, you will only increase performance to 1.02 seconds by going through the trouble of sticking all your classes in one big file. (Of course that also assumes that you need to be parsing every one of those files.)

    Hans

  19. #44
    SitePoint Enthusiast
    Join Date
    Jun 2003
    Location
    Chicago
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hlellelid
    Yes, from benchmarks I've seen removing whitespace & comments provides no noticeable performance increase. It wouldn't be hard to write a quick script to test it ... but I'm lazy

    Anyway, I prefer to have the comments; if I have to look at live code I want to be able to read it.

    In general, I/O can add up when including many files, but there are a couple of things to bear in mind:

    - most operating systems cache file loads in RAM, so subsequent loads of those files (e.g. by other scripts) should be faster. For example, I have attempted to improve site performance by running from a RAM disk, but it made negligible difference on a site that loaded many dozens (probably often > 100) files per request. What happens if you run that benchmark script a number of times in succession?

    - the bottleneck is always the database. At least in my experience, profiling a slow page will always point a big finger at the database connections and queries. Sure it's true that by putting the files in one class mr_jeep has improved the loading time by 2.x %, but the % doesn't really matter in this case because if your page takes 1.1 seconds to load, you will only increase performance to 1.02 seconds by going through the trouble of sticking all your classes in one big file. (Of course that also assumes that you need to be parsing every one of those files.)

    Hans

    For me, a lot of times the I/O is right up there. And as I stated earlier, I would only compile the files I know I need on every page and include others on a as-needed basis.

    McGruff, to you, it wont be worth it. From what I can guess, you'll classify it as hubble space territory and let it be. Signifigant is an opinion, so for some it will be worth it, and others it wont be.

  20. #45
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My concern is that learner programmers can pick up misleading information from threads like this. Being over-concerned with optimisation is a common mistake which often impedes progress towards learning to program well - been there, done that.

    The bottom line is to test.

    As a rough guide I'd expect a single include (with nothing to parse) to take a few ten thousandths of a second...

  21. #46
    SitePoint Evangelist
    Join Date
    Jun 2004
    Location
    California
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you very much for the script mr. jeep. I will be modifying it to suit my needs for another script I am doing and I think I will be able create quite a nice caching system for just the core files with this! 2.18x faster will be a great help in my scripts as they are made for high-traffic. Thank you very much.

  22. #47
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Being over-concerned with optimisation is a common mistake which often impedes progress towards learning to program well
    ...and not being concerned at all about performance is also a mistake , file i/o is a bottleneck, thats hardly a surprise or news to anyone.

    If nothing else this thread helps push that point to those unaware of such , the first time I did tests on speed of includes etc (after seeing a thread such as this) I was amazed at the time spent loading files compared to actually parsing them , I was unaware (though I always assumed) there was a penalty, but not to the extent that I found.

    It seems that many regular's in the advanced PHP forum seem to have one solution & that is to simply throw more hardware at a given issue , nothing wrong with that of course , but also nothing wrong with some basic optimisation , I am not suggesting that MrJeeps solution is the right or only way , only that it is one way of addressing an issue that does exist and that should be understood even if later one chooses to ignore it for good , bad or indifferent reasons.

  23. #48
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Basically there is no way people can argue for putting all their classes in one include file unless they present some data stating how many classes are in the God-include, how many of those classes are actually used, how many files would have been included otherwise (and the I/O time that would have been spent fetching them from the filesystem), a profile of what time was spent doing what, etc.

    Personally, I believe putting all the classes that you know you will need for every page request is perfectly acceptible and would improve performance. This is what I think mr_jeep intended his class to be used for:
    Quote Originally Posted by mr_jeep
    It it very usefull if you always include/require a lot of files to increase speed.
    (emphasis mine)

    However if you put all your classes in your God-include, the time wasted parsing unused classes will increase as the number of classes in your "God" include increases.

    mr_jeep, does your compiler class remove include/require statements from the classes it compiles? specifically include/require statements that point to files that have been compiled into the God-include?

    Another thing, you are forced to know what classes are in the god-include otherwise you might require() a file that has been compiled into the god class which would cause some nasty "Cannot redeclar FooBar" errors.
    Always open to question or ridicule

  24. #49
    Now with customized title Jump's Avatar
    Join Date
    Sep 2002
    Location
    The Restaurant at The End of The Universe
    Posts
    1,423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Different applications need different classes. What would be nice for this script is if it read the directory then presented a list of available classes and check boxes to choose which ones to include. And also the ability to type in the desired name of the file and the directory to save in. This way you could cread single includes specific to the application that needs it.

  25. #50
    SitePoint Zealot mr_jeep's Avatar
    Join Date
    Feb 2004
    Location
    Canada
    Posts
    131
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Different applications need different classes. What would be nice for this script is if it read the directory then presented a list of available classes and check boxes to choose which ones to include. And also the ability to type in the desired name of the file and the directory to save in. This way you could cread single includes specific to the application that needs it.
    I agree 100% with you. However, I don't have time to develop an application like this but i'd be the first using one of these. I think this would be a nice project

    Anyway, I'd like to say I'm glad to see that some of you thinks my works is usefull. It's a nice feeling .

    Thanks
    I'd appreciate if you would tell me if something I wrote is spelled wrong


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
  •