FAQ
I've just checked into APC CVS preliminary support for Lazy Loading classes and functions. This means that rather than copying function entries into EG(function_table) and EG(class_table) when an include happen it will mark the functions/classes as available and only actually insert them into the tables when they are called. This is done via hooks added into the various hash table lookups in PHP. I've placed a patch for PHP_5_3 at:

http://tekrat.com/downloads/bits/apc_lazy_php53.patch

You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading:

apc.lazy_functions=On/Off
apc.lazy_classes=On/OFf

There's still some enhancements that I need to make in both PHP and APC for cleaner code and optimizations, but I wanted to get some early feedback to track down issues. In a final version I'd prefer the above patch to abstract all function lookups into a common function. I would love to hear about success/problems with this, as well as performance results or other suggestions. This was initially implement for Facebook's codebase, and dropped CPU usage by about 30%, today it's required for the site to operate normally. Although I expect smaller gains than this in other codebases (wordpress looks to be about 3%, Joomla and Zend Framework use autoloading and appear to get no visible gains).

Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases.

I look forward to hearing your feedback,

-shire

Search Discussions

  • Ronald Chmara at Feb 22, 2009 at 5:54 am

    On Feb 21, 2009, at 4:10 PM, shire wrote:
    I've just checked into APC CVS preliminary support for Lazy Loading
    classes and functions. This means that rather than copying
    function entries into EG(function_table) and EG(class_table) when
    an include happen it will mark the functions/classes as available
    and only actually insert them into the tables when they are called.
    Wait... so if I understand this right, let's envision a code base
    where, per some random page load, 70 functions are actually called,
    but, oh, 7,000, or even 700,000, are being included for whatever reason?

    The speed optimization is in *not* copying a massive amount of things
    that weren't even needed, or used, in the first place?

    However, there's still the horribly massive speed hit of semi-
    loading, and marking, a fairly large amount of unused, un-needed,
    functions, as available?

    While I do see, and understand, the performance benefit of such a
    coding direction, it's not exactly encouraging well designed code.

    For example:
    <?php
    include(mega-loader.php);
    //which kicks off
    ->include(site-mega-loader.php);
    //which kicks off
    -->include(sub-site-mega-loader.php);
    //which kicks off
    --->include(sub-site-application-loader.php);
    //which kicks off
    ---->include(sub-site-application-feature-loader.php);
    //which kicks off
    ----->include(sub-site-application-function-loader.php);
    //which kicks off
    ------>include(sub-site-application-function-loader-function.php);

    //and the actual code which caused the load?
    my_custom_site_application_echo( "Hello World");

    ?>

    This.... does not make me happy as a coder.

    I do see the benefit of lazy loading, I'm just not very comfortable
    with enabling a philosophy of loading up a massive amount of CPU and
    RAM with "just in case they're wanted" features and code in the first
    place.

    It *should* hurt to load something.

    Code should not be ever loaded unless needed.

    It certainly can boost an APC code set such as facebook, where many
    of those files and functions *will* likely be used in the next 20
    minutes or so, but I also fear that it will encourage programmers to
    load everything they have, every time, just in case they need it....
    and 2Gb apache processes (and APC space) can be.... ugly.

    That being said, I think the idea is good, but the possible mis-uses
    are potentially tough issues.

    -Bop
  • Shire at Feb 22, 2009 at 6:55 am
    Hi Ronald,

    Ronald Chmara wrote:
    Wait... so if I understand this right, let's envision a code base where,
    per some random page load, 70 functions are actually called, but, oh,
    7,000, or even 700,000, are being included for whatever reason?

    The speed optimization is in *not* copying a massive amount of things
    that weren't even needed, or used, in the first place?
    Essentially, yes, this is probably best summed up by the 80/20 rule where we only use 20% of the code etc...

    However, there's still the horribly massive speed hit of semi-loading,
    and marking, a fairly large amount of unused, un-needed, functions, as
    available?
    I don't agree with the description of describing this as a "horribly massive speed hit" at least in comparison with what was happening without lazy loading. Also, like I said there's further iterations I plan to make here, one of these being increasing the performance of this marking functions as available.

    I do see the benefit of lazy loading, I'm just not very comfortable with
    enabling a philosophy of loading up a massive amount of CPU and RAM with
    "just in case they're wanted" features and code in the first place.
    Well I am assuming that this is what a large amount of code does already, except that without lazy loading the situation is significantly worse. Your point that we should be sure this does not encourage poor coding practices is well taken, but it's been my experience that code tends to take this form regardless so I'm hoping to make the best of the situation ;-).

    Also keep in mind that there are cases where you may not know in advance which functions you will/will not call, but it's probably fair to say that the 80/20 rule still holds, so including all the functions you may need is not particularly a misuse of the language, but rather a necessity of a dynamic application and language.

    It certainly can boost an APC code set such as facebook, where many of
    those files and functions *will* likely be used in the next 20 minutes
    or so, but I also fear that it will encourage programmers to load
    everything they have, every time, just in case they need it.... and 2Gb
    apache processes (and APC space) can be.... ugly.
    I'm not entirely clear on where code being used in the next 20 minutes come into play, what differenc does 100 milliseconds vs. 20 minutes make in APC/lazy loading? It's actually likely that only a fraction of the code at Facebook will be used in a request, hence the need for lazy loading. But we need to make all the functions available due to the dynamic nature of the site and PHP itself as we don't know ahead of time which functions we will need to call.

    Thanks for the feedback, and hopefully the above makes sense. I don't want to encourage bad progarmming form and would definitely encourage avoiding this situation if possible, however I think many applications may find this optimization a necessity.

    -shire
  • Mikko Koppanen at Feb 22, 2009 at 4:36 pm

    On Sun, Feb 22, 2009 at 6:55 AM, shire wrote:
    Thanks for the feedback, and hopefully the above makes sense. I don't want
    to encourage bad progarmming form and would definitely encourage avoiding
    this situation if possible, however I think many applications may find this
    optimization a necessity.
    Hello,

    I don't think this patch encourages bad programming any way. It just gives
    more flexibility for the sites that need to focus on performance. I haven't
    had the chance to check the patch yet but as a principle this is something I
    would like to see in future versions of PHP / APC.

    Good work!



    --
    Mikko Koppanen
  • Ronald Chmara at Feb 23, 2009 at 7:47 am

    On Feb 21, 2009, at 10:55 PM, shire wrote:
    Hi Ronald,
    Ronald Chmara wrote:
    Wait... so if I understand this right, let's envision a code base
    where,
    per some random page load, 70 functions are actually called, but, oh,
    7,000, or even 700,000, are being included for whatever reason?
    The speed optimization is in *not* copying a massive amount of things
    that weren't even needed, or used, in the first place?
    Essentially, yes, this is probably best summed up by the 80/20 rule
    where we only use 20% of the code etc...
    Well, I can see 80% actually *used* code, with 20% in there by
    accident.... but 80% unused code? eep! ack! Call the villagers and
    get the torches and pitchforks!...

    ...but environments vary, of course. ;)
    However, there's still the horribly massive speed hit of semi-
    loading,
    and marking, a fairly large amount of unused, un-needed,
    functions, as
    available?
    I don't agree with the description of describing this as a
    "horribly massive speed hit" at least in comparison with what was
    happening without lazy loading.
    Fair enough. Before the patch, for example, I might describe it (80%
    unused, 20% used code) as an "insanely awful, horribly massive speed
    hit", and after the patch, as being reduced to a much lesser
    "horribly massive speed hit", but these are just rhetorical, and
    qualitative, language devices that I used to characterize code issues.

    In both cases, a large amount of CPU is spent on (effectively) doing
    nothing, but your patch (as I understand its design) reduces the
    amount of CPU waste... doing nothing.
    Also, like I said there's further iterations I plan to make here,
    one of these being increasing the performance of this marking
    functions as available.
    One thing I see as quite a beneficial future outcome of your work is
    the ability to further profile code, and be able to seek out code
    that marks massive amounts of functions as "available".... without
    actually ever using them.
    I do see the benefit of lazy loading, I'm just not very
    comfortable with
    enabling a philosophy of loading up a massive amount of CPU and
    RAM with
    "just in case they're wanted" features and code in the first place.
    Well I am assuming that this is what a large amount of code does
    already, except that without lazy loading the situation is
    significantly worse.
    Different code bases and philosophies vary.

    Since much of what I do (enterprise PHP tuning) involves (among many
    other things) finding, and eliminating, such code, I can say with
    great confidence that there certainly are bloat-bases out there that
    load metric hogs-heads of libraries to show a single web email form,
    but there are also code bases which do *not* rely on endless
    libraries, frameworks, additional template abstractions and end user
    libraries, or other pre-determined architectures... to complete the
    simple task of showing an web email form.

    To frame the issue another way, you are trying to make huge,
    complicated, code sets less painful to use, and I am arguing that
    huge, complicated, code sets are a major part of the problem..... but
    since neither of us can wave a magic wand and reduce the problem to
    simple, elegant, code sets, you're reducing the magnitude of pain
    involved. Kudos to you.
    Your point that we should be sure this does not encourage poor
    coding practices is well taken, but it's been my experience that
    code tends to take this form regardless so I'm hoping to make the
    best of the situation ;-).
    There will always be bad code, yes. ;-)

    I'm trying to raise a token flag of discussion/resistance to making
    bad code practices less painful, as it still enables bad code practices.
    Also keep in mind that there are cases where you may not know in
    advance which functions you will/will not call, but it's probably
    fair to say that the 80/20 rule still holds, so including all the
    functions you may need is not particularly a misuse of the
    language, but rather a necessity of a dynamic application and
    language.
    It all depends on the use, and environment, I suppose.
    It certainly can boost an APC code set such as facebook, where
    many of
    those files and functions *will* likely be used in the next 20
    minutes
    or so, but I also fear that it will encourage programmers to load
    everything they have, every time, just in case they need it....
    and 2Gb
    apache processes (and APC space) can be.... ugly.
    I'm not entirely clear on where code being used in the next 20
    minutes come into play, what differenc does 100 milliseconds vs. 20
    minutes make in APC/lazy loading?
    FB seems to have a fair bit of traffic, with a semi-patrolled code
    set, so it's likely that any single APC-loaded function will be
    invoked *eventually*, within an hour or so.

    Contrast this with 1,000 different sites hosted on a box, using a
    less patrolled, fairly unregulated, 1,000 different batches of PHP
    codesets, where "myTotallyCustomDateTime()" can have 1,000 different
    variants, some of which are only actually used once every 3-5 weeks
    or so.

    Lazy loading would (as I understand it) speed up both, but lazy
    loading would also encourage not just one code set, but all code
    sets, to assume that the *language authors*, rather than the
    *developers*, were responsible for making sure CPU was being managed
    efficiently.
    It's actually likely that only a fraction of the code at Facebook
    will be used in a request, hence the need for lazy loading.
    Ouch. Seriously.

    I can't tell you how to build your code, but I think you might
    seriously benefit from:
    a) Lazy Loading (as you've done, great idea)
    b) Using Lazy Loading to find out which apps/code are sucking up
    massive CPU, and taking action as need to help tune, or remove, the
    offending code?
    c) Breaking your Lazy Loading targets out, to where (a hypothetical)
    the mytzyplk_scramble() function/class method is only included and
    thus loaded as needed, rather than (as a guess) a function group (or
    class method group) auto-loaded which may/may not be needed for a
    given page load?

    Does that make sense? Or did you try it already? :)

    -Bop
  • Shire at Feb 23, 2009 at 7:20 pm

    Ronald Chmara wrote:
    On Feb 21, 2009, at 10:55 PM, shire wrote:
    Hi Ronald,
    Ronald Chmara wrote:
    Wait... so if I understand this right, let's envision a code base where,
    per some random page load, 70 functions are actually called, but, oh,
    7,000, or even 700,000, are being included for whatever reason?
    The speed optimization is in *not* copying a massive amount of things
    that weren't even needed, or used, in the first place?
    Essentially, yes, this is probably best summed up by the 80/20 rule
    where we only use 20% of the code etc...
    Well, I can see 80% actually *used* code, with 20% in there by
    accident.... but 80% unused code? eep! ack! Call the villagers and get
    the torches and pitchforks!...
    I should probably be more specific, it's not that you *don't* use the other 80% it's that you use 20% of the code 80% of the time: http://en.wikipedia.org/wiki/Pareto_principle

    Of course I'm abusing this slightly, but this is the *basic* idea, and it's not based on actual usage statistics. In reality you probably use all 100% of your code in smaller chunks depending on the request. As an illustrative example, if you have HTTP requests for setting, retrieving, deleting items in a database which is supported by corresponding functions. In each request you'll only use one of these functions (30%), but you'll still need to load the entire file/class. The goal of lazy loading is to optimize this and similar situations so you don't have to re-organize your code into unfeasibly small files, or in other ways that might inhibit productivity.

    One thing I see as quite a beneficial future outcome of your work is the
    ability to further profile code, and be able to seek out code that marks
    massive amounts of functions as "available".... without actually ever
    using them.
    I think this would be better instrumented through tools actually designed to do this sort of profiling, specifically XDebug, or tools like inclued are very useful.

    http://pecl.php.net/package/xdebug
    http://pecl.php.net/package/inclued

    It's actually likely that only a fraction of the code at Facebook will
    be used in a request, hence the need for lazy loading.
    Ouch. Seriously.

    I can't tell you how to build your code, but I think you might seriously
    benefit from:
    ....
    Does that make sense? Or did you try it already? :)

    I'd rather not enter into a public discussion of Facebook's current optimization tactics outside of this patch, but suffice to say we have implemented many optimization techniques, both in PHP code and Internals, many of which we have and will continue to contribute back to the community. Lazy Loading has been a very necessary and optimal solution to this one aspect of our scalability, thus allowing our engineers to focus more of their time and energy on creating new and exciting features for Facebook.


    Thanks,

    -shire
  • Rodrigo Saboya at Feb 26, 2009 at 1:58 pm

    Ronald Chmara wrote:
    On Feb 21, 2009, at 10:55 PM, shire wrote:
    Hi Ronald,
    Ronald Chmara wrote:
    Wait... so if I understand this right, let's envision a code base where,
    per some random page load, 70 functions are actually called, but, oh,
    7,000, or even 700,000, are being included for whatever reason?
    The speed optimization is in *not* copying a massive amount of things
    that weren't even needed, or used, in the first place?
    Essentially, yes, this is probably best summed up by the 80/20 rule
    where we only use 20% of the code etc...
    Well, I can see 80% actually *used* code, with 20% in there by
    accident.... but 80% unused code? eep! ack! Call the villagers and get
    the torches and pitchforks!...

    ...but environments vary, of course. ;)
    However, there's still the horribly massive speed hit of semi-loading,
    and marking, a fairly large amount of unused, un-needed, functions, as
    available?
    I don't agree with the description of describing this as a "horribly
    massive speed hit" at least in comparison with what was happening
    without lazy loading.
    Fair enough. Before the patch, for example, I might describe it (80%
    unused, 20% used code) as an "insanely awful, horribly massive speed
    hit", and after the patch, as being reduced to a much lesser "horribly
    massive speed hit", but these are just rhetorical, and qualitative,
    language devices that I used to characterize code issues.

    In both cases, a large amount of CPU is spent on (effectively) doing
    nothing, but your patch (as I understand its design) reduces the amount
    of CPU waste... doing nothing.
    Also, like I said there's further iterations I plan to make here, one
    of these being increasing the performance of this marking functions as
    available.
    One thing I see as quite a beneficial future outcome of your work is the
    ability to further profile code, and be able to seek out code that marks
    massive amounts of functions as "available".... without actually ever
    using them.
    I do see the benefit of lazy loading, I'm just not very comfortable with
    enabling a philosophy of loading up a massive amount of CPU and RAM with
    "just in case they're wanted" features and code in the first place.
    Well I am assuming that this is what a large amount of code does
    already, except that without lazy loading the situation is
    significantly worse.
    Different code bases and philosophies vary.

    Since much of what I do (enterprise PHP tuning) involves (among many
    other things) finding, and eliminating, such code, I can say with great
    confidence that there certainly are bloat-bases out there that load
    metric hogs-heads of libraries to show a single web email form, but
    there are also code bases which do *not* rely on endless libraries,
    frameworks, additional template abstractions and end user libraries, or
    other pre-determined architectures... to complete the simple task of
    showing an web email form.

    To frame the issue another way, you are trying to make huge,
    complicated, code sets less painful to use, and I am arguing that huge,
    complicated, code sets are a major part of the problem..... but since
    neither of us can wave a magic wand and reduce the problem to simple,
    elegant, code sets, you're reducing the magnitude of pain involved.
    Kudos to you.
    Your point that we should be sure this does not encourage poor coding
    practices is well taken, but it's been my experience that code tends
    to take this form regardless so I'm hoping to make the best of the
    situation ;-).
    There will always be bad code, yes. ;-)

    I'm trying to raise a token flag of discussion/resistance to making bad
    code practices less painful, as it still enables bad code practices.
    Also keep in mind that there are cases where you may not know in
    advance which functions you will/will not call, but it's probably fair
    to say that the 80/20 rule still holds, so including all the functions
    you may need is not particularly a misuse of the language, but rather
    a necessity of a dynamic application and language.
    It all depends on the use, and environment, I suppose.
    It certainly can boost an APC code set such as facebook, where many of
    those files and functions *will* likely be used in the next 20 minutes
    or so, but I also fear that it will encourage programmers to load
    everything they have, every time, just in case they need it.... and 2Gb
    apache processes (and APC space) can be.... ugly.
    I'm not entirely clear on where code being used in the next 20 minutes
    come into play, what differenc does 100 milliseconds vs. 20 minutes
    make in APC/lazy loading?
    FB seems to have a fair bit of traffic, with a semi-patrolled code set,
    so it's likely that any single APC-loaded function will be invoked
    *eventually*, within an hour or so.

    Contrast this with 1,000 different sites hosted on a box, using a less
    patrolled, fairly unregulated, 1,000 different batches of PHP codesets,
    where "myTotallyCustomDateTime()" can have 1,000 different variants,
    some of which are only actually used once every 3-5 weeks or so.

    Lazy loading would (as I understand it) speed up both, but lazy loading
    would also encourage not just one code set, but all code sets, to assume
    that the *language authors*, rather than the *developers*, were
    responsible for making sure CPU was being managed efficiently.
    It's actually likely that only a fraction of the code at Facebook
    will be used in a request, hence the need for lazy loading.
    Ouch. Seriously.

    I can't tell you how to build your code, but I think you might seriously
    benefit from:
    a) Lazy Loading (as you've done, great idea)
    b) Using Lazy Loading to find out which apps/code are sucking up massive
    CPU, and taking action as need to help tune, or remove, the offending code?
    c) Breaking your Lazy Loading targets out, to where (a hypothetical) the
    mytzyplk_scramble() function/class method is only included and thus
    loaded as needed, rather than (as a guess) a function group (or class
    method group) auto-loaded which may/may not be needed for a given page
    load?

    Does that make sense? Or did you try it already? :)

    -Bop
    Hi,

    Ronald, I think you are overreacting a little bit. It may be that proper
    written could would get no benefit from this patch since it would not
    load unneeded code and this patch ends up speeding up environments where
    such "correct" loading isn't done. I don't think that's a reason to
    disqualify a feature that brings benefits with no significant drawbacks.

    For the average PHP programmer, the language will simply "get faster".
    That can't be bad in any way. It doesn't encourage you to write bad
    code, it just doesn't kick you in the nuts when you do.

    Regards
    Rodtigo Saboya
  • Robin Burchell at Feb 26, 2009 at 2:07 pm

    On Thu, Feb 26, 2009 at 1:58 PM, Rodrigo Saboya wrote:
    <snip>
    For the average PHP programmer, the language will simply "get faster". That
    can't be bad in any way. It doesn't encourage you to write bad code, it just
    doesn't kick you in the nuts when you do.
    It's probably also worth noting that in a lot of cases, you really
    *won't* use a lot of what you load, at least initially. If you're
    working in an OOP fashion, for example, you won't use every method at
    once on an object, but you're still going to have to pull the whole
    object in to use it.

    If you're writing functional code, the same applies: there will often
    be some generic parts of stuff that you won't use for *every* request
    that you still won't split out into a seperate file simply because
    they are *often* used..

    I think I'd have to guess that around 40% of the code I load gets used
    on a single request, but that is because of the aforementioned problem
    of using classes. It's not that big a worry to me, because I use APC
    to lessen the hit, and thankfully(? :)) I don't have thousands of r/s,
    just a few hundred.

    Seems like a good change to me.
  • Ronald Chmara at Feb 27, 2009 at 2:38 am

    On Feb 26, 2009, at 5:58 AM, Rodrigo Saboya wrote:
    Ronald, I think you are overreacting a little bit. It may be that
    proper written could would get no benefit from this patch since it
    would not load unneeded code and this patch ends up speeding up
    environments where such "correct" loading isn't done. I don't think
    that's a reason to disqualify a feature that brings benefits with
    no significant drawbacks.

    For the average PHP programmer, the language will simply "get
    faster". That can't be bad in any way. It doesn't encourage you to
    write bad code, it just doesn't kick you in the nuts when you do.
    Sold. (The best arguments are always the short ones).

    As I said: "I'm trying to raise a token flag of discussion/
    resistance", but nobody in the discussion seems to have found any
    really important downsides, yet, with only me raising *any* sort of
    flag (though I admit it's not much of one).

    :)

    -Bop
  • Gopal V at Feb 26, 2009 at 2:33 pm

    shire wrote:

    http://tekrat.com/downloads/bits/apc_lazy_php53.patch

    You should be able to apply the above patch to the latest PHP_5_3
    branch, and recompile the latest APC CVS against it. Two ini settings
    enable/display lazy loading:

    apc.lazy_functions=On/Off
    apc.lazy_classes=On/OFf Awesome!
    Alternative implementations would include replacing the function entries
    with an internal function that would load the opcodes when called,
    however I found this implementation to be problematic, still requires
    changes to PHP, and would also require inserting entries into the
    function/class tables which itself ends up being an expensive task for
    extremely large codebases.
    I still haven't given up on the executor hooks. But can't argue with
    code that works (yes, it works for most of my tests).

    I should finish up the RO patches in place so that we can catch stuff
    being overwritten in shm without locks - reflection, xdebug and suhosin
    looks like potential culprits here.

    Cheers,
    Gopal
    --
    If I learn from my mistakes, pretty soon I'll know everything
  • Rasmus Lerdorf at Feb 26, 2009 at 4:35 pm

    Gopal V wrote:
    shire wrote:
    http://tekrat.com/downloads/bits/apc_lazy_php53.patch

    You should be able to apply the above patch to the latest PHP_5_3
    branch, and recompile the latest APC CVS against it. Two ini settings
    enable/display lazy loading:

    apc.lazy_functions=On/Off
    apc.lazy_classes=On/OFf
    Awesome!
    Yup, I am all for the lazy loading patch as well. I don't think people
    really realize how much code they load that is never run. Especially
    all the folks with massive front controllers.
    Alternative implementations would include replacing the function
    entries with an internal function that would load the opcodes when
    called, however I found this implementation to be problematic, still
    requires changes to PHP, and would also require inserting entries into
    the function/class tables which itself ends up being an expensive task
    for extremely large codebases.
    I still haven't given up on the executor hooks. But can't argue with
    code that works (yes, it works for most of my tests).

    I should finish up the RO patches in place so that we can catch stuff
    being overwritten in shm without locks - reflection, xdebug and suhosin
    looks like potential culprits here.
    I wouldn't worry about xdebug at all. We should probably just turn off
    the opcode cache part when xdebug is active if it is a problem.

    -Rasmus
  • Shire at Feb 26, 2009 at 7:00 pm

    Rasmus Lerdorf wrote:
    Gopal V wrote:
    shire wrote:
    http://tekrat.com/downloads/bits/apc_lazy_php53.patch

    You should be able to apply the above patch to the latest PHP_5_3
    branch, and recompile the latest APC CVS against it. Two ini settings
    enable/display lazy loading:

    apc.lazy_functions=On/Off
    apc.lazy_classes=On/OFf
    Awesome!
    Yup, I am all for the lazy loading patch as well. I don't think people
    really realize how much code they load that is never run. Especially
    all the folks with massive front controllers.

    Thanks, I would be interested in hearing how successful it is on different setups just to validate it. I'll start making some more cleanups to the patches and more optimizations in the next month or two so hopefully we'll see some additional improvements in the code and performance.


    Alternative implementations would include replacing the function
    entries with an internal function that would load the opcodes when
    called, however I found this implementation to be problematic, still
    requires changes to PHP, and would also require inserting entries into
    the function/class tables which itself ends up being an expensive task
    for extremely large codebases.
    I still haven't given up on the executor hooks. But can't argue with
    code that works (yes, it works for most of my tests).

    By executor hooks do you mean actually the executor hooks in Zend, or replacing a stub in the function table like I described? I like the idea of stubbing out function table entries, but I think this makes it difficult to avoid the costs of updating the function table, I'm hoping that I can make some optimizations that cut this down so I guess we'll see in a while if I'm able to do that as it might shed some light on how much we can gain by going one way or the other etc. If you're thinking of something else (I know we discussed this before, but maybe I misunderstood), I'd like to hear the details. ;-)


    I should finish up the RO patches in place so that we can catch stuff
    being overwritten in shm without locks - reflection, xdebug and suhosin
    looks like potential culprits here.

    I thought this was awesome when I read your blog post, should be great!


    I wouldn't worry about xdebug at all. We should probably just turn off
    the opcode cache part when xdebug is active if it is a problem.
    I agree for the general case, in our development environment though this might cause some pains. But we could always start there and see how it goes. I agree that Xdebug isn't really a use case we always need to optimize for.


    -shire
  • Rasmus Lerdorf at Feb 26, 2009 at 7:06 pm

    shire wrote:
    I agree for the general case, in our development environment though this
    might cause some pains. But we could always start there and see how it
    goes. I agree that Xdebug isn't really a use case we always need to
    optimize for.
    Is it ever a case we need to optimize for? If you are running xdebug,
    you aren't worried about execution speed. You certainly aren't going to
    be running your PHP under xdebug in any sort of production environment.

    -Rasmus
  • Shire at Feb 26, 2009 at 7:24 pm

    Rasmus Lerdorf wrote:
    shire wrote:
    I agree for the general case, in our development environment though this
    might cause some pains. But we could always start there and see how it
    goes. I agree that Xdebug isn't really a use case we always need to
    optimize for.
    Is it ever a case we need to optimize for? If you are running xdebug,
    you aren't worried about execution speed. You certainly aren't going to
    be running your PHP under xdebug in any sort of production environment.

    I agree I don't see a case for ever using XDebug in a production environment with APC (unless you're providing some sort of developer service, and even then). Obivously the user cache needs to function as you could be debugging something related. In our development environment I'm just not sure how much additional time this will cost us in addition to xdebug. I believe it takes 6 seconds (roughly there might be other crud going on there) for us to compile all the code into opcodes for execution, so tacking this on to xdebug might cause some headaches for developers.

    But like I said, I think this case is pretty extraordinary, so for the sake of getting this great feture in if we need to disable this then I think I'm fine with figuring out some other solution to it should it actually be a problem at a later date. Even if I can disable this in APC then that might be enough to work around it.

    -shire

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 22, '09 at 12:10a
activeFeb 27, '09 at 2:38a
posts14
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase