Hey:
On Thu, Jan 22, 2015 at 3:36 PM, Dmitry Stogov wrote:
> Hi,
>
> Xinchen already tried something similar, but it made PHP slower, because it
> made access to Bucket->key->h more expensive - two loads with most probably
> two CPU cache misses instead of one.
yes, the patch is here: https://git
Hi all,
On Thu, Jan 22, 2015 at 3:42 PM, Yasuo Ohgaki wrote:
> Since it should be faster, I tried to took some benchmarks. Then I found
> extremely slow
> session (files handler) performance with CLI built in web server
> regardless of may patch.
>
> The script I used is
>
> session_start();
>
Hi,
Xinchen already tried something similar, but it made PHP slower, because it
made access to Bucket->key->h more expensive - two loads with most probably
two CPU cache misses instead of one.
Thanks. Dmitry.
On Thu, Jan 22, 2015 at 9:43 AM, Benjamin Coutu wrote:
> Hi,
>
> Currently a hashtabl
Single query/answer at a time?
On Jan 22, 2015 1:44 PM, "Yasuo Ohgaki" wrote:
> Hi all,
>
> On Thu, Jan 22, 2015 at 2:05 PM, Yasuo Ohgaki wrote:
>
> > This patch boosts PHP application performance a lot when session data
> > have not changed. It's faster than benchmark in the wiki because hashin
On 22 Jan 2015 06:43, "Benjamin Coutu" wrote:
>
> Hi,
>
> Currently a hashtable bucket has to store both, the numeric index "h" and
a potential pointer to a string key "key".
>
> There is room for improvement here because "h" and "key" are conceptually
mutually exclusive. I therefore propose to un
Hi all,
On Thu, Jan 22, 2015 at 2:05 PM, Yasuo Ohgaki wrote:
> This patch boosts PHP application performance a lot when session data
> have not changed. It's faster than benchmark in the wiki because hashing
> has removed.
>
Since it should be faster, I tried to took some benchmarks. Then I fou
Hi,
Currently a hashtable bucket has to store both, the numeric index "h" and a
potential pointer to a string key "key".
There is room for improvement here because "h" and "key" are conceptually
mutually exclusive. I therefore propose to unionize "h" and "key" to
effectively save the overhead
Hi all,
On Sun, Mar 16, 2014 at 3:11 PM, Yasuo Ohgaki wrote:
> Modified patch for this RFC is here
>
> https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
>
> There may be leftover still. I'll check it again later, but it's
> appreciated if you find any.
>
> Someone asked if I'm
Hi Nikita,
On Thu, Jan 22, 2015 at 12:42 AM, Nikita Popov wrote:
> On Wed, Jan 21, 2015 at 2:57 PM, Dmitry Stogov wrote:
>
>> Hi,
>>
>> Yeah, I think changing foreach behaviour in more consistent and efficient
>> way may make sense.
>> If we won't use HashTable.nInternalPointer we won't need to
Hi,
On 22/01/15 13:47, Xinchen Hui wrote:
> myabe, you could send these patch via bugs.php.net, or github PR?
>
> it's better than mails :)
Yes, I also submit them to php-src. -
https://github.com/php/php-src/pull/1014
I send them to internals@ for if people want to comment on it.
But, as suggested
Hey:
On Thu, Jan 22, 2015 at 2:27 AM, Joshua Rogers wrote:
> ---
>
> These issues are not serious(only triggerable by the runner/caller of the PHP
> program), so no need to make them private.
>
> sapi/litespeed/lsapi_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Jan 22, 2015 12:21 AM, "Tony Marston" wrote:
>
> "Kristopher" wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
>
>>
>> On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
>> wrote:
>>
>>>
>>> You are totally missing the point. It is the principle of having
Am 21.01.2015 um 20:39 schrieb Rasmus Lerdorf:
> Log:
> Slightly modify and merge PR#105 from @MegaManSec
>
> Bugs:
> https://bugs.php.net/105
I think the commit email script needs to be updated to handle PR#NNN
"links".
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
---
These issues are not serious(only triggerable by the runner/caller of the PHP
program), so no need to make them private.
sapi/litespeed/lsapi_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sapi/litespeed/lsapi_main.c b/sapi/litespeed/lsapi_main.c
index d767306..8144706 100644
-
---
These issues are not serious(only triggerable by the runner/caller of the PHP
program), so no need to make them private.
sapi/litespeed/lsapi_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sapi/litespeed/lsapi_main.c b/sapi/litespeed/lsapi_main.c
index 2b2385c..d
---
These issues are not serious(only triggerable by the runner/caller of the PHP
program), so no need to make them private.
sapi/litespeed/lsapilib.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c
index
On Wed, Jan 21, 2015 at 12:21 PM, Tony Marston
wrote:
>
>
> Because I would rather fight for valid principles than give in. To quote
> Emiliano Zapata "It is better to die on your feet than live on your knees".
I don't think constructors are what he had in mind.
"Kristopher" wrote in message
news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com...
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
wrote:
You are totally missing the point. It is the principle of having to spent
unknown quantities of time in refactoring my code for nothi
On Wed, January 21, 2015 12:32, Derick Rethans wrote:
> On Wed, 21 Jan 2015, Anatol Belski wrote:
>
>
>> On Wed, January 21, 2015 11:57, Anatol Belski wrote:
>>
>>> On Wed, January 21, 2015 11:17, Derick Rethans wrote:
>>>
>>>
On Wed, 21 Jan 2015, Anatol Belski wrote:
> I'll back
On Wed, Jan 21, 2015 at 2:57 PM, Dmitry Stogov wrote:
> Hi,
>
> Yeah, I think changing foreach behaviour in more consistent and efficient
> way may make sense.
> If we won't use HashTable.nInternalPointer we won't need to copy immutable
> arrays.
> The same for nested foreach on the same array.
>
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston
wrote:
>
> You are totally missing the point. It is the principle of having to spent
> unknown quantities of time in refactoring my code for nothing more than a
> frivolous and unnecessary break in BC. It does not fi a bug or a security
> issue, there
Yasuo Ohgaki wrote on 21/01/2015 02:48:
I don't think that's an either/or situation: in most cases, it
would be up to the user to create that independent iterator,
because there's no general algorithm for cloning one that the
engine could use. (Think of an iterator proxying a dat
"Kristopher" wrote in message
news:CAF9U7z-bkYRDwAL8CA4_=1dhorl0evp_mzwf6qwqscwdf7n...@mail.gmail.com...
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston
wrote:
@tony: What's really interesting is that all this time you've spent arguing
could have been used to update your code and make this no l
"Ralf Lang" wrote in message news:54beb145.7030...@b1-systems.de...
#1 and #2 may be considered to be genuine improvements by the user
community, but #3 most certainly will not. It does not matter how you
try to dress it up, forcing your end users to jump through hoops before
they can upgrade i
""François Laupretre"" wrote in message
news:018d01d03501$c0a877d0$41f96770$@tekwire.net...
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for
Hi Dmitry,
One could use an external pointer for the iteration and flag the hashtable
while being iterated.
In order to preserve the constraint that for-each is conceptually working on a
copy, one would have to duplicate (zend_array_dup) the hastable everytime one
alters it (e.g. adding/changi
Hi,
Yeah, I think changing foreach behaviour in more consistent and efficient
way may make sense.
If we won't use HashTable.nInternalPointer we won't need to copy immutable
arrays.
The same for nested foreach on the same array.
We could also eliminate all the HashPosition magic introduced to keep
On Wed, 21 Jan 2015, Anatol Belski wrote:
> On Wed, January 21, 2015 11:57, Anatol Belski wrote:
> > On Wed, January 21, 2015 11:17, Derick Rethans wrote:
> >
> >> On Wed, 21 Jan 2015, Anatol Belski wrote:
> >>
> >>> I'll backport it to 5.6. Also would add the Pierre's suggestion so
> >>> those d
On Wed, January 21, 2015 11:57, Anatol Belski wrote:
> On Wed, January 21, 2015 11:17, Derick Rethans wrote:
>
>> On Wed, 21 Jan 2015, Anatol Belski wrote:
>>
>>
>>
>>> I'll backport it to 5.6. Also would add the Pierre's suggestion so
>>> those defines are only used when it's not inside PHP, as un
Ralf Lang wrote on 20/01/2015 23:23:
On 20.01.2015 22:27, Rowan Collins wrote:
Hi All!
Occasionally, in various discussions, waiting for the next major release
is described as "maybe another 10 years", but I think that's a very
pessimistic prediction. It's more reasonable to expect it in half t
On Wed, January 21, 2015 11:17, Derick Rethans wrote:
> On Wed, 21 Jan 2015, Anatol Belski wrote:
>
>
>> I'll backport it to 5.6. Also would add the Pierre's suggestion so
>> those defines are only used when it's not inside PHP, as under
>> circumstances it could lead to different defines or confli
On 21/01/15 03:19, Levi Morrison wrote:
> That aside, I sure hope that PHP 8 is not another ten years after PHP 7 :)
Accepting that PHP5.4 was essentially when PHP6 level of breakages
occurred then one is generally in line with the 5/6 year cycle anyway!
--
Lester Caine - G8HFL
-
On Wed, 21 Jan 2015, Anatol Belski wrote:
> I'll backport it to 5.6. Also would add the Pierre's suggestion so
> those defines are only used when it's not inside PHP, as under
> circumstances it could lead to different defines or conflicts. This is
> easy done through the timelib_config.h inclu
Hi Derick,
On Wed, January 21, 2015 10:22, Derick Rethans wrote:
> On Wed, 21 Jan 2015, Anatol Belski wrote:
>
>
>> On Tue, January 20, 2015 22:08, Derick Rethans wrote:
>>
>>>
>>> This commit makes timelib include a PHP specific file. timelib also
>>> lives as an external library (https://github.
On Wed, 21 Jan 2015, Anatol Belski wrote:
> On Tue, January 20, 2015 22:08, Derick Rethans wrote:
> >
> > This commit makes timelib include a PHP specific file. timelib also
> > lives as an external library (https://github.com/derickr/timelib)
> > and is used by other projects. Because it's sort
On Wed, Jan 21, 2015 at 9:54 AM, Anatol Belski wrote:
> Hi Derick,
>
> On Tue, January 20, 2015 22:08, Derick Rethans wrote:
>> Hi Anatol!
>>
>>
>> (Yes, I realise this is from more than a year ago)
>>
>>
>> This commit makes timelib include a PHP specific file. timelib also
>> lives as an externa
Hi Derick,
On Tue, January 20, 2015 22:08, Derick Rethans wrote:
> Hi Anatol!
>
>
> (Yes, I realise this is from more than a year ago)
>
>
> This commit makes timelib include a PHP specific file. timelib also
> lives as an external library (https://github.com/derickr/timelib) and is
> used by othe
37 matches
Mail list logo
