Re: [PHP-DEV] turning strlen() into an opcode
On Sat, 9 Nov 2002, George Schlossnagle wrote: Hehe. I should attach the patch, eh? Yes, you should... but you still didn't do that :-) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
Funny, it's in the message my mua said it sent (the 2nd time). How is this? It's also in pear/PECL/optimizer/zend.patch On Sunday, November 10, 2002, at 06:11 AM, Derick Rethans wrote: On Sat, 9 Nov 2002, George Schlossnagle wrote: Hehe. I should attach the patch, eh? Yes, you should... but you still didn't do that :-) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
Here's the patch that Dan and I put together for the optimizer we talked about at the conference. It basically provides a defaulted-to-null function pointer that is the default case for the main execute() loop. This allows people to define their own opcodes without having to copy the source code for execute part and parcel into their own zend_execute() just to add a new opcodes. This is useful both for optimizers (like the one now in PECL/optimizer), as well as for implementing custom opcodes like what you want here without a huge engine patch. George On Friday, November 8, 2002, at 05:18 PM, Andrei Zmievski wrote: On Sat, 09 Nov 2002, Andi Gutmans wrote: I am very much against anything like this. Improving strlen()'s performance only will have a negligible performance impact on a real world script. With the same kind of argument you could probably find 10-20 functions which would be faster if you'd make opcodes for them. That's not really what you'd want to do. Also, the patch isn't quite the same functionality wise because strlen in your patch is a reserved word. This isn't my main problem though as it could be solved. Just out of curiousity, what are the problems with making it a reserved word and how could it be solved? If you want to really help improve performance of real-world scripts then try and find a way to improve performance of *all* function calls, i.e., of the extension API; and not by moving functions from the extension API into the core. No big deal. This just came up at the PHP conference in Germany during a chat with George and Thies. -Andrei http://www.gravitonic.com/ * If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
Hehe. I should attach the patch, eh? On Saturday, November 9, 2002, at 09:15 PM, George Schlossnagle wrote: Here's the patch that Dan and I put together for the optimizer we talked about at the conference. It basically provides a defaulted-to-null function pointer that is the default case for the main execute() loop. This allows people to define their own opcodes without having to copy the source code for execute part and parcel into their own zend_execute() just to add a new opcodes. This is useful both for optimizers (like the one now in PECL/optimizer), as well as for implementing custom opcodes like what you want here without a huge engine patch. George On Friday, November 8, 2002, at 05:18 PM, Andrei Zmievski wrote: On Sat, 09 Nov 2002, Andi Gutmans wrote: I am very much against anything like this. Improving strlen()'s performance only will have a negligible performance impact on a real world script. With the same kind of argument you could probably find 10-20 functions which would be faster if you'd make opcodes for them. That's not really what you'd want to do. Also, the patch isn't quite the same functionality wise because strlen in your patch is a reserved word. This isn't my main problem though as it could be solved. Just out of curiousity, what are the problems with making it a reserved word and how could it be solved? If you want to really help improve performance of real-world scripts then try and find a way to improve performance of *all* function calls, i.e., of the extension API; and not by moving functions from the extension API into the core. No big deal. This just came up at the PHP conference in Germany during a chat with George and Thies. -Andrei http://www.gravitonic.com/ * If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] turning strlen() into an opcode
I've made a small patch that turns strlen() into a statement executed by
the engine instead of a function. The reasoning is that something that
integral should probably be in the engine. I haven't done hard
benchmarking but it seems to improve performance of that particular
piece of code by about 25%. Feedback is welcome.
-Andrei http://www.gravitonic.com/
* UNIX, isn't that some archaic form of DOS? - our job applicant *
Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.124
diff -u -2 -b -w -B -r1.124 zend_builtin_functions.c
--- zend_builtin_functions.c21 Oct 2002 08:42:32 - 1.124
+++ zend_builtin_functions.c8 Nov 2002 21:15:20 -
-30,5 +30,4
static ZEND_FUNCTION(func_get_arg);
static ZEND_FUNCTION(func_get_args);
-static ZEND_NAMED_FUNCTION(zend_if_strlen);
static ZEND_FUNCTION(strcmp);
static ZEND_FUNCTION(strncmp);
-80,5 +79,4
ZEND_FE(func_get_arg, NULL)
ZEND_FE(func_get_args, NULL)
- { strlen, zend_if_strlen, NULL },
ZEND_FE(strcmp, NULL)
ZEND_FE(strncmp,NULL)
-244,19 +242,4
zend_hash_next_index_insert(return_value-value.ht, element,
sizeof(zval *), NULL);
}
-}
-/* }}} */
-
-
-/* {{{ proto int strlen(string str)
- Get string length */
-ZEND_NAMED_FUNCTION(zend_if_strlen)
-{
- zval **str;
-
- if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, str) == FAILURE) {
- ZEND_WRONG_PARAM_COUNT();
- }
- convert_to_string_ex(str);
- RETVAL_LONG((*str)-value.str.len);
}
/* }}} */
Index: zend_compile.c
===
RCS file: /repository/Zend/zend_compile.c,v
retrieving revision 1.239
diff -u -2 -b -w -B -r1.239 zend_compile.c
--- zend_compile.c 3 Nov 2002 15:16:44 - 1.239
+++ zend_compile.c 8 Nov 2002 21:15:21 -
-2101,4 +2101,15
}
+void zend_do_strlen(znode *result, znode *expr TSRMLS_DC)
+{
+ zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
+
+ opline-opcode = ZEND_STRLEN;
+ opline-result.op_type = IS_TMP_VAR;
+ opline-result.u.var = get_temporary_variable(CG(active_op_array));
+ opline-op1 = *expr;
+ SET_UNUSED(opline-op2);
+ *result = opline-result;
+}
void zend_do_foreach_begin(znode *foreach_token, znode *array, znode
*open_brackets_token, znode *as_token, int variable TSRMLS_DC)
Index: zend_compile.h
===
RCS file: /repository/Zend/zend_compile.h,v
retrieving revision 1.144
diff -u -2 -b -w -B -r1.144 zend_compile.h
--- zend_compile.h 4 Aug 2002 06:39:44 - 1.144
+++ zend_compile.h 8 Nov 2002 21:15:21 -
-326,4 +326,6
void zend_do_isset_or_isempty(int type, znode *result, znode *variable TSRMLS_DC);
+void zend_do_strlen(znode *result, znode *expr TSRMLS_DC);
+
void zend_do_foreach_begin(znode *foreach_token, znode *array, znode
*open_brackets_token, znode *as_token, int variable TSRMLS_DC);
void zend_do_foreach_cont(znode *value, znode *key, znode *as_token TSRMLS_DC);
-522,4 +524,6
#define ZEND_SEND_VAR_NO_REF 106
+
+#define ZEND_STRLEN 107
/* end of block */
Index: zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.315
diff -u -2 -b -w -B -r1.315 zend_execute.c
--- zend_execute.c 3 Nov 2002 15:16:45 - 1.315
+++ zend_execute.c 8 Nov 2002 21:15:21 -
-2360,4 +2360,20
}
NEXT_OPCODE();
+ case ZEND_STRLEN: {
+ zval tmp_val, *val =
+get_zval_ptr(EX(opline)-op1, EX(Ts), EG(free_op1), BP_VAR_R);
+ if (val-type != IS_STRING) {
+ tmp_val = *val;
+ zval_copy_ctor(tmp_val);
+ convert_to_string(tmp_val);
+ val = tmp_val;
+ }
+
+EX(Ts)[EX(opline)-result.u.var].tmp_var.value.lval = val-value.str.len;
+ EX(Ts)[EX(opline)-result.u.var].tmp_var.type
+= IS_LONG;
+ if (val == tmp_val) {
+ zval_dtor(tmp_val);
+ }
+ FREE_OP(EX(Ts), EX(opline)-op1,
+EG(free_op1));
+ }
+ NEXT_OPCODE();
Re: [PHP-DEV] turning strlen() into an opcode
Hi, I am very much against anything like this. Improving strlen()'s performance only will have a negligible performance impact on a real world script. With the same kind of argument you could probably find 10-20 functions which would be faster if you'd make opcodes for them. That's not really what you'd want to do. Also, the patch isn't quite the same functionality wise because strlen in your patch is a reserved word. This isn't my main problem though as it could be solved. If you want to really help improve performance of real-world scripts then try and find a way to improve performance of *all* function calls, i.e., of the extension API; and not by moving functions from the extension API into the core. Andi At 04:17 PM 11/8/2002 -0500, Andrei Zmievski wrote: I've made a small patch that turns strlen() into a statement executed by the engine instead of a function. The reasoning is that something that integral should probably be in the engine. I haven't done hard benchmarking but it seems to improve performance of that particular piece of code by about 25%. Feedback is welcome. -Andrei http://www.gravitonic.com/ * UNIX, isn't that some archaic form of DOS? - our job applicant * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
On Sat, 09 Nov 2002, Andi Gutmans wrote: I am very much against anything like this. Improving strlen()'s performance only will have a negligible performance impact on a real world script. With the same kind of argument you could probably find 10-20 functions which would be faster if you'd make opcodes for them. That's not really what you'd want to do. Also, the patch isn't quite the same functionality wise because strlen in your patch is a reserved word. This isn't my main problem though as it could be solved. Just out of curiousity, what are the problems with making it a reserved word and how could it be solved? If you want to really help improve performance of real-world scripts then try and find a way to improve performance of *all* function calls, i.e., of the extension API; and not by moving functions from the extension API into the core. No big deal. This just came up at the PHP conference in Germany during a chat with George and Thies. -Andrei http://www.gravitonic.com/ * If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
At 05:18 PM 11/8/2002 -0500, Andrei Zmievski wrote: On Sat, 09 Nov 2002, Andi Gutmans wrote: I am very much against anything like this. Improving strlen()'s performance only will have a negligible performance impact on a real world script. With the same kind of argument you could probably find 10-20 functions which would be faster if you'd make opcodes for them. That's not really what you'd want to do. Also, the patch isn't quite the same functionality wise because strlen in your patch is a reserved word. This isn't my main problem though as it could be solved. Just out of curiousity, what are the problems with making it a reserved word and how could it be solved? What if you wanted to have a constant STRLEN? It would break. It could be solved by doing strcmp()'s during the compilation of a function and checking if the function name is strlen(). If you want to really help improve performance of real-world scripts then try and find a way to improve performance of *all* function calls, i.e., of the extension API; and not by moving functions from the extension API into the core. No big deal. This just came up at the PHP conference in Germany during a chat with George and Thies. I could have guessed Thies had a hand in it :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
Do you think strlen() is actually called that often? And isn't it a relatively quick function as it is? Just seems like you are optimizing a function that isn't actually called that often and when it is called having a 25% speedup on a function that takes a tiny fraction of the overall execution time isn't going to be noticeable. I wouldn't be against perhaps opcoding some functions, just not sure strlen() would be my first candidate. -Rasmus On Fri, 8 Nov 2002, Andrei Zmievski wrote: I've made a small patch that turns strlen() into a statement executed by the engine instead of a function. The reasoning is that something that integral should probably be in the engine. I haven't done hard benchmarking but it seems to improve performance of that particular piece of code by about 25%. Feedback is welcome. -Andrei http://www.gravitonic.com/ * UNIX, isn't that some archaic form of DOS? - our job applicant * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote: I've made a small patch that turns strlen() into a statement executed by the engine instead of a function. The reasoning is that something that integral should probably be in the engine. I haven't done hard benchmarking but it seems to improve performance of that particular piece of code by about 25%. Feedback is welcome. I'd be more interested in seeing a more generic len() function (a la Python) that would return the length of the variable passed to it (the number of characters in a string, then number of elements in an array). Actually, I suppose extending count() to handle strings would be mostly equivalent. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] turning strlen() into an opcode
On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote: I've made a small patch that turns strlen() into a statement executed by the engine instead of a function. The reasoning is that something that integral should probably be in the engine. I haven't done hard benchmarking but it seems to improve performance of that particular piece of code by about 25%. Feedback is welcome. I'd be more interested in seeing a more generic len() function (a la Python) that would return the length of the variable passed to it (the number of characters in a string, then number of elements in an array). Actually, I suppose extending count() to handle strings would be mostly equivalent. ughh, no more syntatic sugar, php is sweet enough how it is :) -Sterling -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Sterling Hughes [EMAIL PROTECTED] Did I help you? Consider a gift: http://wishlist.edwardbear.org/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
