Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
--
Stanislav Malyshev, Zend Software Architect
On 10.06.2008 11:04, Stanislav Malyshev wrote:
Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
Hi!
So here's my offer: if two core committers, or even just one, were
willing to champion this feature, I will take full responsibility for
"if" is redundant here - at least three core committers are already for
this feature. In any case, not rehashing all the past arguments and
their vali
Hello
On 2008-06-09, at 14:58, Scott MacVicar wrote:
There is rabin-karp too but its worse case is O(nm) so that might
not be ideal, perhaps we should try to compare all of them.
OK. I think RK will not be much better than original piece of code
which runs in time o(n + m) i most cases
On 2008-06-09, at 14:43, Antony Dovgal wrote:
On 09.06.2008 15:39, Michal Dziemianko wrote:
Hello,
Here: http://212.85.117.53/DIFF.txt is small patch that will
speed up following functions:
strpos,
stripos,
strrpos
strripos,
and probably some others (all that use zend_memnstr/php_memnstr
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be nice to tag it before the change, just in case.
Oooh, exciting stuff :)
- Steph
--
Stanislav M
Hi,
The proposed patch for PHP improves the executor.
At first it eliminates direct execute() recursion so the following
script won't produce SIGSEGV anymore (It'll produce memory overflow
error instead).
Note that in case some extension (e.q. xdebug) override zend_execute(),
VM will use
Out of curiosity, what's the slowdown without fastcall?
Despite the potential slowdown, I still think this is the way to go. The
engine isn't supposed to crash!
Nuno
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "PHP Internals List"
Cc: "Andi Gutmans" <[EMAIL PRO
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
Thanks. Dmitry.
Despite the potential slowdown, I still think this is the way to go. The
engine isn't supposed to
Dmitry Stogov wrote:
The proposed patch for PHP improves the executor.
ZEND_GCC_VERSION >= 3400 means >= GCC 3.4.0, right?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
yeah, I know. I was asking what's the slowdown that this patch introduces
without the fastcall bits.
I'm asking thi
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert_to_unicode_ex
Would the cleanup include the engine - i.e. all the UG-ly stuff in
macros, functions, etc. - or only ext/* part?
--
Stanislav Malyshev, Zend Softw
Hi Stas,
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert_to_unicode_ex
Would the cleanup include the engine - i.e. all the UG-ly stuff in
macros, functions, etc. - or only ext/* part?
Scott's working on t
I'm working on the patch to remove stuff from Zend/*, I've yet to change
any of the macros. Will most likely leave that to last.
Scott
Stanislav Malyshev wrote:
- Changed:
- ZEND_STR_TYPE -> IS_UNICODE
- convert_to_text -> convert_to_unicode
- convert_to_text_ex -> convert
The recursion elimination itself doesn't show any significant speed
difference.
Thanks. Dmitry.
Nuno Lopes wrote:
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
Exactly. The "fastcall" attribute wasn't supported before.
Thanks. Dmitry.
Sebastian Bergmann wrote:
Dmitry Stogov wrote:
The proposed patch for PHP improves the executor.
ZEND_GCC_VERSION >= 3400 means >= GCC 3.4.0, right?
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
Dmitry Stogov wrote:
Exactly. The "fastcall" attribute wasn't supported before.
As 3.4 is quite old this should not be a problem. I somehow read 4.3
initially ;-)
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5
Hello Dmitry,
Tuesday, June 10, 2008, 1:11:57 PM, you wrote:
> Index: Zend/zend.h
> ===
> RCS file: /repository/ZendEngine2/zend.h,v
> retrieving revision 1.293.2.11.2.9.2.20
> diff -u -p -d -r1.293.2.11.2.9.2.20 zend.h
> --- Zend/ze
I will do it before commit. Didn't have time to check Windows version yet.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, June 10, 2008, 1:11:57 PM, you wrote:
Index: Zend/zend.h
===
RCS file: /repository/ZendEngin
I am trying to call CG(function_table) from within my
PHP_RINIT_FUNCTION() and from what I have found I need to call
TSRMSLS_FETCH() first to populate the function table in a thread safe way.
When I run the extension I get:
dyld: lazy symbol binding failed: Symbol not found: _TSRMSLS_FETCH
Refe
Hi!
I am trying to call CG(function_table) from within my
PHP_RINIT_FUNCTION() and from what I have found I need to call
TSRMSLS_FETCH() first to populate the function table in a thread safe way.
That's TSRMLS_FETCH() (you have extra S).
--
Stanislav Malyshev, Zend Software Architect
[EMAIL P
> That's TSRMLS_FETCH() (you have extra S).
So now I have:
PHP_RINIT_FUNCTION(vardumpoverload)
{
zend_function *orig_1;
TSRMLS_FETCH();
/* Override require_once with our own function */
zend_hash_find(CG(function_table), "require_once", 13, (void
**)&orig_1);
VARDUMPOVERLOA
So now I have:
PHP_RINIT_FUNCTION(vardumpoverload)
{
zend_function *orig_1;
TSRMLS_FETCH();
You don't need fetch here, RINIT already gets it as a parameter.
When I don't use TSRMLS_FETCH(); at all I get a "Bus error" when running
the extension and calling require_once().
You should
Yes, good idea. PRE-BFUC (PRE-BigFreakingUnicodeCleanup)
-Andrei
Stanislav Malyshev wrote:
Hi!
Oh, and third - if nobody gets back to us by Friday over these patches
we'll just commit :) Don't know about Felipe's larger corner, but I
tested mine to death already.
I think it would also be n
Hello geeks,
This email is to confirm that $str{42} is deprecated in favour of
$str[42] as of PHP 6. There is some confusion so let's make something
official here.
A little history:
- May, 2001: $str[42]: is documented as deprecated since PHP 4
- Nov, 2005: $str[42]: kept while $str{42} i
Hi,
I don't get this deprecation and thus the forced code change at all.
Considering the amount of code using this style, see
http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php
and given that no PHP code change has been done I would rather suggest
removing the
Hi Markus,
Am Mittwoch, den 11.06.2008, 01:04 +0200 schrieb Markus Fischer:
[...]
> I don't get this deprecation and thus the forced code change at all.
> Considering the amount of code using this style, see
> http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php
>
Correct me if I'm wrong but wasn't that the last decision we made about it the
last time this was brought up? Just undocument it. Totally. It exists, only
works with strings (right?! :) and is not recommended. So simply make it
disappear from the docs. "See no evil, hear no evil, speak no evil..
>So unless this thread changes something, an E_DEPRECATED will be added to
HEAD (PHP >6.0.0) for curly brace string access ( $str{42} ) and the
documentation will remain as is.
I'm well aware that I don't get a vote, so I'll skip the +1.
That being said, I'd like to argue in favour of depricating
Hi,
$str{} was considered a best practice for a while so as you can see via
Google Code Search it's been used quite a bit.
I take the blame for introducing it with the intention to not only
create a better separation between arrays and string offsets but by also
then allowing for a cleaner impleme
30 matches
Mail list logo
