Johannes Schlüter wrote:
On Fri, 2009-03-13 at 18:27 +0100, Kalle Sommer Nielsen wrote:
I must admit that I think it would be bad to delay 5.3 more and have
another beta because of this,
Well, according to Dmitry (didn't test it myself) this doesn't bring
real improvements so I don't think it'
On Fri, 2009-03-13 at 18:27 +0100, Kalle Sommer Nielsen wrote:
> I must admit that I think it would be bad to delay 5.3 more and have
> another beta because of this,
Well, according to Dmitry (didn't test it myself) this doesn't bring
real improvements so I don't think it's needed.
> however if
Hi
2009/3/13 Pierre Joye :
> hi,
>
> Then I would rather have a beta2 and not a RC. This change while being
> great may require more tweaks, and as Marcus suggested, we could push
> APC in too while being at it. I'm all for it (both :).
I must admit that I think it would be bad to delay 5.3 more
hi,
Then I would rather have a beta2 and not a RC. This change while being
great may require more tweaks, and as Marcus suggested, we could push
APC in too while being at it. I'm all for it (both :).
Cheers,
On Wed, Mar 11, 2009 at 5:13 PM, Lukas Kahwe Smith wrote:
>
> On 11.03.2009, at 17:10,
Hi,
I've fixed all the issues I found in the original patch (attached).
However then I realized that speed-up was caused by bugs that leaded to
render pages in improper way. After fix the speed-up disappear. :(
So now I don't see any reason to include it into 5.3.
Thanks. Dmitry.
Lukas Kahw
On 11.03.2009, at 20:58, shire wrote:
Lukas Kahwe Smith wrote:
Can we get this patch to release quality by this weekend?
So that people can test it on Monday/Tuesday ahead of RC1?
I don't see this being a problem, I do have a few items I'd like to
point out for feedback/suggestions:
1) C
Hi!
there is no such thing. Let's either do it now or go for 5.4.
Can we please stop trying new big features each time we approach RC? 5.3
is not last PHP version ever, and it's long overdue. Can't we just
release it without putting more and more potentially unstable changes
into it, and th
Hello Lukas,
Wednesday, March 11, 2009, 11:15:23 PM, you wrote:
> On 11.03.2009, at 19:55, Marcus Boerger wrote:
>> Last but not least, Lukas, what happened, to putting APC into core?
> That was planned for PHP 6.0.
there is no such thing. Let's either do it now or go for 5.4.
> regards,
>
On 11.03.2009, at 19:55, Marcus Boerger wrote:
Last but not least, Lukas, what happened, to putting APC into core?
That was planned for PHP 6.0.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n
Lukas Kahwe Smith wrote:
Can we get this patch to release quality by this weekend?
So that people can test it on Monday/Tuesday ahead of RC1?
I don't see this being a problem, I do have a few items I'd like to point out
for feedback/suggestions:
1) Currently it doesn't support method level la
Hello Lukas,
Wednesday, March 11, 2009, 5:10:57 PM, you wrote:
> Dmitry Stogov wrote:
>> Hi Shire,
>>
>> I run patched APC on a number of real-life applications and got more
>> than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on
>> ZendFramework (41 req/sec instead of 32), however m
Lukas Kahwe Smith wrote:
On 11.03.2009, at 17:10, Rasmus Lerdorf wrote:
Anyway, it's very good job and 20-30% speedup on some real-life
applications makes sense to include it into 5.3 (from my point of view).
Makes sense to me as well, especially since I don't see any drawbacks
for non-accele
On 11.03.2009, at 17:10, Rasmus Lerdorf wrote:
Anyway, it's very good job and 20-30% speedup on some real-life
applications makes sense to include it into 5.3 (from my point of
view).
Makes sense to me as well, especially since I don't see any drawbacks
for non-accelerated scripts.
I also t
Dmitry Stogov wrote:
> Hi Shire,
>
> I run patched APC on a number of real-life applications and got more
> than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on
> ZendFramework (41 req/sec instead of 32), however most applications
> (drupal, qdig, typo3, wordpress) didn't show signific
Hi Shire,
I run patched APC on a number of real-life applications and got more
than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on
ZendFramework (41 req/sec instead of 32), however most applications
(drupal, qdig, typo3, wordpress) didn't show significant speed
difference. As was
shire wrote:
Dmitry Stogov wrote:
Hi,
Personally, I like the patch except for some small possible tweaks, and
I believe it can't make any harm with lazy loading disabled.
Thanks, what are the tweaks you'd like to see so I can try to include them?
I thought about different semantics for d
Dmitry Stogov wrote:
Hi,
Personally, I like the patch except for some small possible tweaks, and
I believe it can't make any harm with lazy loading disabled.
Thanks, what are the tweaks you'd like to see so I can try to include them?
Could you provide some benchmark results?
I was hoping
Hi,
Personally, I like the patch except for some small possible tweaks, and
I believe it can't make any harm with lazy loading disabled.
Could you provide some benchmark results?
APC patch to play with it and see advantages/disadvantages?
Thanks. Dmitry.
shire wrote:
Lukas Kahwe Smith wrote
Lukas Kahwe Smith wrote:
On 22.02.2009, at 01:10, 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 fu
On 22.02.2009, at 01:10, 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
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 is
On Thu, Feb 26, 2009 at 1:58 PM, Rodrigo Saboya
wrote:
> 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
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
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 whatev
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 o
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
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 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
28 matches
Mail list logo
