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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
