Hi Levi,
thanks for your reply.
>> after quite some some I've been finally able to put my hands again on
>> PDO. I know the timing is not ideal, but I hope it's not too late for
>> adding a couple more features and fixes into 5.5.
>
> Purely bug fixes are probably welcome for PHP 5.5 but new fea
On Tue, 04 Jun 2013 22:12:41 +0200, Dmitry Stogov wrote:
This "good" algorithm that doesn't work well for "worse" cases makes
about 15% slowdown of ZF2 based applications.
It also slowdowns wordpress and other apps, but not so significantly.
It's definitely doesn't work well for real-life ap
Hi Gustavo,
This "good" algorithm that doesn't work well for "worse" cases makes about
15% slowdown of ZF2 based applications.
It also slowdowns wordpress and other apps, but not so significantly.
It's definitely doesn't work well for real-life applications :(
Something must be dome (e.g. usage o
On Mon, 03 Jun 2013 10:55:16 +0200, Dmitry Stogov wrote:
I didn't look into the code yet (and really don't like to do it), but we
just noticed terrible performance degradation of strtr() function between
5.4.11 and 5.4.15 coming probably after your changes.
$ cat strtr.php
"11", "g"=>"22"));
On 04/06/13 12:08, Pierre Joye wrote:
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
wrote:
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and
consist
On Tue, 2013-06-04 at 14:32 +0200, Ferenc Kovacs wrote:
> What do you think about adding the $options and $limit arguments to those
> two Exception methods?
With debug_backtrace() adding those reduces the work the engine has to
do while collecting the data, getTrace() is simply passing a
pre-exist
Hi,
What do you think about adding the $options and $limit arguments to those
two Exception methods?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
wrote:
> Hey :-),
>
>
> On 02/06/13 08:52, Johannes Schlüter wrote:
>>>
>>> It would be a *gigantic* patch, but the userland effects should be
>>> minimal (the only changes would be supporting longer strings, and
>>> consistent 64
>>> bit int su
On Tue, 2013-06-04 at 10:41 +0200, Ivan Enderlin @ Hoa wrote:
> > History shows that such gigantic patches are often not finished and
> > done as people underestimate the size of PHP and the fact that all
> > etensions have to be checked which for this case means checking
> > each external lib for
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and consistent 64
bit int support). The performance considerations should be minimal for
non-legacy code (as both
+1 , that will make a big diff .
I'm here to help others to go forward.
Julien.P
On Tue, Jun 4, 2013 at 8:33 AM, Pierre Joye wrote:
> On Tue, Jun 4, 2013 at 6:59 AM, Michael Wallner wrote:
>
> > +1 for the idea
> > +1 for Z_STRSIZE
>
> at least Z_STRSIZET for the reason explained earlier :)
11 matches
Mail list logo
