Re: [PHP-DEV] [PATCH] Redirect on Error
On Wed, 27 Nov 2002, Sascha Schumann wrote: On Wed, 27 Nov 2002, Stig S. Bakken wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
-1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
On Wed, 27 Nov 2002, Derick Rethans wrote: On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: User complains that maximum length of a line used by fscanf is too short (he has lines 1600 chars). Looking at file.h I agree (it's only 512). The user requested two options: 1) Add an optional length field. No way to do that without breaking parameter list. :( We can't really do that, users will get pissed :) 2) Increase to a larger arbitrary number. This simply has the problem that it may prove too short eventually as well. Yeah, IMO it doesn't solve anything. Plus I came up with a third option: 3) Create an .ini entry to specify the maximum length used. I think this has the best overall return on it. I don't like us adding a new ini entry for this, I think we should try another option: 4) Make sure we can use fscanf on a dynamically sized buffer. This will definitely the hardest solution, but also the most beautiful one. [4] is definitely the best option. formatted_print.c already does something similar. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
On Sat, 30 Nov 2002, Stig S. Bakken wrote: 4) Make sure we can use fscanf on a dynamically sized buffer. This will definitely the hardest solution, but also the most beautiful one. [4] is definitely the best option. formatted_print.c already does something similar. Stig, it's already fixed :) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Sat, 30 Nov 2002, Sascha Schumann wrote: -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? Sascha, I asked if you had any suggestions because I really wanted to hear if you had any suggestions, not because I wanted to dive into a verbal trench war. It doesn't have to be errno-style error codes, as long as the solution has the right balance between completeness and simplicity to make sure that all extension and PEAR package maintainers start using them. But assuming that our goals are fairly similar after all, I take the liberty of re-phrasing your mail as two suggestions: 1. make a naming scheme for error codes/symbols that is scalable, easily machine readable but also human readable 2. partition the error symbol space with a resolution to optimize management overhead Are we on wavelength yet? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 12:00 30.11.2002, Sascha Schumann wrote: -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? - Sascha +1 If you write a README.ERROR_CODES and we can get a consensus on it i will commit the functions needed to main.c as already posed. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $_get['variable']
Anyone know how to allow pre 4.0.3 code which was written when you could call get parsed variables as $variable etc tyo work on the new version of php which doesnt allow this ??? Thanks Ben Paul Proactive Innovations LTD www.proactiveinnovations.co.uk -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
We talkes about this at our March Doc meeting. The problem is that the different doc systems mostly started out from the initial phpdoc repositories system, and developed on their own ways. Reuniting the build systems under one umbrella would be quite a hard task, and I don't know who can volunteer on this. It obviously needs more then one person from every doc team, who understands the system used there, and can work to unite them. In March, the central build system for all php documentation project seemed to be a faraway dream... Well, it also needs to be mentioned, that if you look at the different parts (php-dev, pear-dev) they also have different coding standards, CVS rules, etc.), so it's still a trouble for developers. Indeed, this would be huge task. Plus, is having a big doc system better than two smaller units ? There is already a lot of work to move from peardoc to peardoc2. Well, I think we had a wrong picture about PECL (or at least I had), that the PECL extensions were distributed separately. If all the extensions are in PECL, the manual should contain the core ones, bundled with PHP, that's for sure. We would also like to gain some on moving docs to PEAR/PECL doc tree as there will be less to translate for the core PHP manual. I don't think so that any translation team can handle the current size of the manual and keep it up to date. Some translations had backed off when faced the size of the work to do to make the translation complete, or manage a translation at some stage. From an insider view, I can say that the Hungarian translation also faces such problems now, we are unable to at least keep the translation up to date... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_get['variable']
At 12:27 PM 11/30/02 +, Benjamin Paul wrote: Anyone know how to allow pre 4.0.3 code which was written when you could call get parsed variables as $variable etc tyo work on the new version of php which doesnt allow this ??? This really belongs on the php-general list, this list is for the development OF php, not develpment with php. In php.ini change the setting for REGISTER_GLOBALS to on. Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (1012 total including feature requests) ===[*Configuration Issues] 13561 Assigned --without-pear prevent install of php-config,phpize,... 19282 Won't fix Place php4ts.dll into \sapi 20490 Open enable versioning not supported on OSX 20689 Won\'t fix php_admin_value disable_functions not working as it should ===[*General Issues]== 20195 Open make install doesnt set permissions ===[*Languages/Translation]=== 11975 Won't fix mix of hebrew english 13014 Won't fix hebrevc () 20166 Open Unicode (Slovenian) characters are not displayed correctly 20468 Feedback strcoll doesn't work ===[*Network Functions]=== 15639 Suspended detecting end of UDP packets ===[Apache related]=== 14409 Open request for nonexistent file does not return 404 error 15529 Open ap_cleanup_for_exec not used when creating 17837 Won't fix PHP 'handles' permission problems rather than letting Apache do it 18523 Feedback httpd Memory consumption with new PHP 19113 Open HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use 19292 Critical random error: open_basedir restriction in effect. File is in wrong directory 19378 Open Parse error in PHP executable as Apache CGI 20053 Open apachesuexecphp-cgiignore_user_abort - problem with cancelled connections 20104 Open unhandled exception with multiple requests 20190 Critical Random mem corruption: zend_get_executed_filename() mismatch 20476 Feedback Apache cannot load libphp4.so into server. Undefined symbol IS_SLASH_P 20643 Open long POST fields get truncated 20657 Feedback Rundom Apache/PHP Bug 20665 Feedback Memory leaks and allocation problems ===[Apache2 related]== 17098 Analyzed apache sending 304 - not modified header 17414 Open Segfaults on restart 17566 Open phpinfo() causes load of 2+ 17868 Verified Doesn't work two and more !--include-- directives of PHP code on different OS 18371 Open --enable-discard-path breaks php-cgi 18957 Won't fix multiple definitions 19452 Feedback Apache2 with php4 freeze on HP-UX 11.00 19739 Open php-4.2.3 fails to Install with Apache 2.0.42 on AIX 5.1 ML2 19787 Won\'t fix Can not load module 19918 Open no libphp4.so produced 20568 Feedback Apache2/PHP 4.2.3 File Upload Corruption 20569 Open Apache fails when restarting 20701 Open ld: can't locate file for: -laprutiland after ===[Arrays related]=== 18829 Won\'t fix array_pop, array_shift, array_push... functions very slow with large arrays 20251 Won\'t fix Can't assign values to array in loop. ===[BC math related]== 13551 Open BC functions apply decimal places argument also on arguments 20495 Open BC Math is not Thread Safe, but is in Win32 TS distribution ===[Bzip2 Related] 20598 Feedback bzip2 doesn't create new files ===[CCVS related]= 10447 Won\'t fix ccvs_*() functions segfault when given invalid session ID ===[Class/Object related]= 15675 Suspended get_class() returns only lower chars 17637 Analyzed constructors in classes (Back to PHP3) 20065 Open References to object members seem to be backwards 20520 Open Nonsymetric data syncronization with references 20531 Open Object property association broken 20709 Feedback Session variable getting mysteriously set ===[COM related]== 15771 Suspended cannot pass value to image field by ado 16375 Suspended Feature: Support for VARIANT multi dimensional arrays 19150 Open Overloaded COM Property Set Leaks Memory 20100 Open Com Performance/Memory issues 20282 Open COM memory leak ===[Compile Failure]== 1298 Verified need to use -taso with Netscape LDAP libs 7643 Open APXS compile fails with not a DSO 10108 Open cc 1501:218 file XXX contains an incorrect file suffix 14245 Verified make install fails on apxs 15587 Feedback basic_functions.c and dns.c fail to compile due to incompatible parameters 17820 Won't fix php.ini-dist not copied 18358 Won't fix Recode doesn't compile with apache2 19555 Open GNU pthreads issue? 19973 Open compile zlib and pcre as shared fails 20336 Feedback won't compile with gcc 3.2 20395 Feedback A handful of #ifdef's to
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
Is there any reason the ifdef __cplusplus doesn't work? There shouldn't be any need for extra processing or config options. J Smith wrote: How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with the proper extern C stuff? That way there's no need for skeleton.cpp and just a few changes need to be made in skeleton.c. J Sascha Schumann wrote: On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend.c zend.h zend_builtin_functions.c
Andi Gutmans wrote: andiSat Nov 30 05:51:56 2002 EDT Modified files: /Zend zend.c zend.h zend_builtin_functions.c Log: - debug_print_backtrace (by George Schlossnagle [EMAIL PROTECTED]) MFH? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend.c zend.h zend_builtin_functions.c
At 17:05 30.11.2002, Sebastian Bergmann wrote: Andi Gutmans wrote: andiSat Nov 30 05:51:56 2002 EDT Modified files: /Zend zend.c zend.h zend_builtin_functions.c Log: - debug_print_backtrace (by George Schlossnagle [EMAIL PROTECTED]) MFH? New functionality? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
Is there any reason the ifdef __cplusplus doesn't work? There shouldn't be any need for extra processing or config options. well, i think c++ code might confuse people just starting out writing a C extension... -Sterling J Smith wrote: How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with the proper extern C stuff? That way there's no need for skeleton.cpp and just a few changes need to be made in skeleton.c. J Sascha Schumann wrote: On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- 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] [PATCH] Changes to ext_skel for C++
At 18:07 30.11.2002, Sterling Hughes wrote: Is there any reason the ifdef __cplusplus doesn't work? There shouldn't be any need for extra processing or config options. well, i think c++ code might confuse people just starting out writing a C extension... -Sterling But there are more thinks they will not understand. So why making it more complex and harder to understand the whole stuff for all of us? J Smith wrote: How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with the proper extern C stuff? That way there's no need for skeleton.cpp and just a few changes need to be made in skeleton.c. J Sascha Schumann wrote: On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend.c zend.h zend_builtin_functions.c
Marcus Börger wrote: New functionality? It vitaly improves new functionality (debug_backtrace()). -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: Zend / zend.c zend.h zend_builtin_functions.c
On Sat, 30 Nov 2002, Sebastian Bergmann wrote: Marcus Börger wrote: New functionality? It vitaly improves new functionality (debug_backtrace()). IMO it's too late; we're in RC2 already. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Hashtables
Hey all I was playing around and I'm running into a problem with a hashtable... Basically, it's segfaulting my code :) Specifically, I'm trying to return the number of items in the hash... if(zend_hash_num_elements(hash) == 0) Which causes the following: Program received signal SIGSEGV, Segmentation fault. zend_hash_num_elements (ht=0x0) at /home/php/php4/Zend/zend_hash.c:988 988 return ht-nNumOfElements; Anyone know the steps I need to do in order for something like this to work? If it hasn't been initialized, how do I tell other than checking the elements? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hashtables
On Sat, 30 Nov 2002, John Coggeshall wrote:
Hey all
I was playing around and I'm running into a problem with a hashtable...
Basically, it's segfaulting my code :) Specifically, I'm trying to
return the number of items in the hash...
if(zend_hash_num_elements(hash) == 0)
Which causes the following:
Program received signal SIGSEGV, Segmentation fault.
zend_hash_num_elements (ht=0x0) at /home/php/php4/Zend/zend_hash.c:988
988 return ht-nNumOfElements;
You need to check if your ht actually is initialized, at the moment it
is NULL, and if you want to dereference that, you get a segfault.
if (!hash || (zend_hash_num_elements(hash) == 0)) {
}
should work.
Derick
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bugfixing #20663
Following patch allows longer error messages within Zend.
marcus
cvs -z3 -q diff zend.c (in directory S:\php4-HEAD\Zend)
Index: zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.193
diff -u -r1.193 zend.c
--- zend.c 30 Nov 2002 11:20:25 - 1.193
+++ zend.c 30 Nov 2002 16:55:20 -
@@ -703,8 +703,6 @@
}
-#define ZEND_ERROR_BUFFER_SIZE 1024
-
ZEND_API void zend_error(int type, const char *format, ...)
{
va_list args;
@@ -775,18 +773,7 @@
ALLOC_INIT_ZVAL(z_error_filename);
ALLOC_INIT_ZVAL(z_error_lineno);
ALLOC_INIT_ZVAL(z_context);
- z_error_message-value.str.val = (char *)
emalloc(ZEND_ERROR_BUFFER_SIZE);
-
-#ifdef HAVE_VSNPRINTF
- z_error_message-value.str.len =
vsnprintf(z_error_message-value.str.val, ZEND_ERROR_BUFFER_SIZE, format,
args);
- if (z_error_message-value.str.len
ZEND_ERROR_BUFFER_SIZE-1) {
- z_error_message-value.str.len =
ZEND_ERROR_BUFFER_SIZE-1;
- }
-#else
- strncpy(z_error_message-value.str.val, format,
ZEND_ERROR_BUFFER_SIZE);
- /* This is risky... */
- /* z_error_message-value.str.len =
vsprintf(z_error_message-value.str.val, format, args); */
-#endif
+ z_error_message-value.str.len =
vspprintf(z_error_message-value.str.val, 0, format, args);
z_error_message-type = IS_STRING;
z_error_type-value.lval = type;
[PHP-DEV] Zend fast cache
Hey, I was checking the CVS logs, and I read :: revision 1.13 date: 2001/11/26 17:27:59; author: andi; state: Exp; lines: +1 -1 - Turn off fast cache until we make sure it performs well. - The best solution is probably to limit its size. I was just wondering what was wrong, and what it would take to get this thing up and running... Thies and I were looking at a little hack, similiar in nature to this, with preallocating a pool of zval's, and it yielded a 5% performance increase (all hacking credit goes to thies btw :). If we preallocated some basic, often used types, i think we'd get a nice performance increase, perhaps even if we initialized in sapi modes a few structures in MINIT, we could reuse those instead of creating and destroying which is currently quite expensive? -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
At 02:59 PM 11/30/2002 -0500, Sterling Hughes wrote: Hey, I was checking the CVS logs, and I read :: revision 1.13 date: 2001/11/26 17:27:59; author: andi; state: Exp; lines: +1 -1 - Turn off fast cache until we make sure it performs well. - The best solution is probably to limit its size. I was just wondering what was wrong, and what it would take to get this thing up and running... Thies and I were looking at a little hack, similiar in nature to this, with preallocating a pool of zval's, and it yielded a 5% performance increase (all hacking credit goes to thies btw :). First of all, let me just say that I wouldn't be too excited about 5% performance difference either way. I already told Thies that from my experience 5% is within the error margin and can change according to compile flags, platform and so on. The reason why the fast cache didn't work well was because it created quite a bit of memory fragmentation which killed MT servers and also made PHP take up too much memory. If we preallocated some basic, often used types, i think we'd get a nice performance increase, perhaps even if we initialized in sapi modes a few structures in MINIT, we could reuse those instead of creating and destroying which is currently quite expensive? That said, I do think that if we can get very fast code to pre-allocate zval's it would be a good idea (hopefully we could get more than 5% increase). I already have an idea for how I would want such an API to look like and I was planning to write it. It would also be useful for Zend objects which are preallocated today but if a realloc() were to be reached it would take quite some time (although one or two realloc()'s wouldn't be terrible). My idea is a two dimensional array. We'd allocate 2^n of memory blocks and assign it to array[0]. Once these are full we'd allocate another 2^n memory blocks and realloc() array to size of 2 and make array[1] point to it. The index to a block would be X and to find the right position it'd be array[X/2^n][X%2^n] of course as the length of each array is a power of two we wouldn't actually need to use division and modulo so it'd be fast. As we don't have templates in C we might be able to put all of this inline in a header file and with macros create such a fast allocating pool for some of the most used types specifically I think it'd be useful for zval's, objects and possible hash tables. I wouldn't overdo the amount of types I'd add to this pool because unless they are allocated and freed extremely often we wouldn't notice a speed difference. But remember what I said about 5% :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
At 02:59 PM 11/30/2002 -0500, Sterling Hughes wrote: Hey, I was checking the CVS logs, and I read :: revision 1.13 date: 2001/11/26 17:27:59; author: andi; state: Exp; lines: +1 -1 - Turn off fast cache until we make sure it performs well. - The best solution is probably to limit its size. I was just wondering what was wrong, and what it would take to get this thing up and running... Thies and I were looking at a little hack, similiar in nature to this, with preallocating a pool of zval's, and it yielded a 5% performance increase (all hacking credit goes to thies btw :). First of all, let me just say that I wouldn't be too excited about 5% performance difference either way. I already told Thies that from my experience 5% is within the error margin and can change according to compile flags, platform and so on. perhaps... this was 5% worse case though, comparing to similairly compiled source trees. In some cases it yielded 15-30% percent, but that can be as you say, attributed to flukes. Still, it would follow that having a memory cache would be a good thing, even if it does only show 5% (on a small script btw)... The reason why the fast cache didn't work well was because it created quite a bit of memory fragmentation which killed MT servers and also made PHP take up too much memory. If we preallocated some basic, often used types, i think we'd get a nice performance increase, perhaps even if we initialized in sapi modes a few structures in MINIT, we could reuse those instead of creating and destroying which is currently quite expensive? That said, I do think that if we can get very fast code to pre-allocate zval's it would be a good idea (hopefully we could get more than 5% increase). I already have an idea for how I would want such an API to look like and I was planning to write it. It would also be useful for Zend objects which are preallocated today but if a realloc() were to be reached it would take quite some time (although one or two realloc()'s wouldn't be terrible). no it wouldn't, and you've also gotta look @ this in terms of what would cause a realloc(), for example, say we have a 16 k pool, hardly anything, and yet we'd need to have _a ton_ of concurrently allocated zvals in order to fill that up. Plus, while the realloc would be expensive, it would be better than doing that many mallocs. Anyhow, we pretty much agree, soo :) My idea is a two dimensional array. We'd allocate 2^n of memory blocks and assign it to array[0]. Once these are full we'd allocate another 2^n memory blocks and realloc() array to size of 2 and make array[1] point to it. The index to a block would be X and to find the right position it'd be array[X/2^n][X%2^n] of course as the length of each array is a power of two we wouldn't actually need to use division and modulo so it'd be fast. As we don't have templates in C we might be able to put all of this inline in a header file and with macros create such a fast allocating pool for some of the most used types specifically I think it'd be useful for zval's, objects and possible hash tables. I wouldn't overdo the amount of types I'd add to this pool because unless they are allocated and freed extremely often we wouldn't notice a speed difference. But remember what I said about 5% :) hrm. :) My only question is really about sequential accesses. for the purpose of example let's pretend its just for zvals... (pool is our pool array of zval structs) ALLOC_ZVAL() - Do we have a zval available? - yes! - return pool[0][0] ALLOC_ZVAL() ... - return pool[0][1] ALLOC_ZVAL() ... - return pool[0][2] FREE_ZVAL() - Clear memory @ pool[0][1] ALLOC_ZVAL() - Do we have a zval available? - return pool[0][3] or do we return pool[0][1] The problem I see with an array approach from an api perspective is simply when a bucket is free'd, in order to have efficient memory usage, we'd need a second level array scan for every ALLOC_ZVAL(). Perhaps a linked list would be a better choice for this, as we can just be smart about bucket access, and eliminate the need for a scan (could be possible I'm missing something?) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
How does searching the freelist work in this? How is this faster than say a 3-level page table implementation? That said, I do think that if we can get very fast code to pre-allocate zval's it would be a good idea (hopefully we could get more than 5% increase). I already have an idea for how I would want such an API to look like and I was planning to write it. It would also be useful for Zend objects which are preallocated today but if a realloc() were to be reached it would take quite some time (although one or two realloc()'s wouldn't be terrible). My idea is a two dimensional array. We'd allocate 2^n of memory blocks and assign it to array[0]. Once these are full we'd allocate another 2^n memory blocks and realloc() array to size of 2 and make array[1] point to it. The index to a block would be X and to find the right position it'd be array[X/2^n][X%2^n] of course as the length of each array is a power of two we wouldn't actually need to use division and modulo so it'd be fast. As we don't have templates in C we might be able to put all of this inline in a header file and with macros create such a fast allocating pool for some of the most used types specifically I think it'd be useful for zval's, objects and possible hash tables. I wouldn't overdo the amount of types I'd add to this pool because unless they are allocated and freed extremely often we wouldn't notice a speed difference. But remember what I said about 5% :) Andi -- 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] Zend fast cache
On Saturday, November 30, 2002, at 07:17 PM, Sterling Hughes wrote: The problem I see with an array approach from an api perspective is simply when a bucket is free'd, in order to have efficient memory usage, we'd need a second level array scan for every ALLOC_ZVAL(). Perhaps a linked list would be a better choice for this, as we can just be smart about bucket access, and eliminate the need for a scan (could be possible I'm missing something?) I agree, a singly linked list seems like a no-brainer; it's an ideal memory-pool data structure because inserts and deletes occur only at the front of the list (so they're constant-time), the links are free, and the implementation is straightforward. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
The problem I see with an array approach from an api perspective is simply when a bucket is free'd, in order to have efficient memory usage, we'd need a second level array scan for every ALLOC_ZVAL(). Perhaps a linked list would be a better choice for this, as we can just be smart about bucket access, and eliminate the need for a scan (could be possible I'm missing something?) A number of memory allocators use a multi-tiered page table for this. basically for each object type you have a array of N pointers to level 1 objects and a freelist for them, basically tier one has N elements that each contain a freelist bitmask value and an array of pointers to level 2 objects. Level 2 objects have a freelist of N allocations for the desired object type and pointers to each of them. This may be what Andi was talking about, but it wasn't clear to me from his description. So you get N^3 aloocations you can track, and a freelist search involves looking at 3 bitmasks. Significantly faster than a linked list implementation. By keeping a separate tree for each allocation type (or at least allocation size), you also end up with basically no fragmentation. -Sterling -- 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] Zend fast cache
A little off-list discussion has sold me on the linked list implementation. Seems very fast and very simple. George On Saturday, November 30, 2002, at 07:53 PM, Daniel Cowgill wrote: On Saturday, November 30, 2002, at 07:17 PM, Sterling Hughes wrote: The problem I see with an array approach from an api perspective is simply when a bucket is free'd, in order to have efficient memory usage, we'd need a second level array scan for every ALLOC_ZVAL(). Perhaps a linked list would be a better choice for this, as we can just be smart about bucket access, and eliminate the need for a scan (could be possible I'm missing something?) I agree, a singly linked list seems like a no-brainer; it's an ideal memory-pool data structure because inserts and deletes occur only at the front of the list (so they're constant-time), the links are free, and the implementation is straightforward. -- 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] Zend fast cache
On Sat, 30 Nov 2002, George Schlossnagle wrote: A little off-list discussion has sold me on the linked list implementation. Seems very fast and very simple. O(1) operations are hard to beat. Note that free lists are not primarily about speed, they are also an extremely helpful tool in the fight against memory fragmentation. That said, IRCG has been using single-linked lists for its free lists (3 or 4 data structures) since its inception. I'm moving IRCG right now to a multi-process model and still need to evaluate whether a central free list (based in shared memory and protected by a semaphore) actually works that well. For example, lock contention issues could affect the performance. Some systems in the kernel world use per-node (=CPU) locks which might prove to be a necessary step for applications as well. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
At 07:17 PM 11/30/2002 -0500, Sterling Hughes wrote: hrm. :) My only question is really about sequential accesses. for the purpose of example let's pretend its just for zvals... (pool is our pool array of zval structs) ALLOC_ZVAL() - Do we have a zval available? - yes! - return pool[0][0] ALLOC_ZVAL() ... - return pool[0][1] ALLOC_ZVAL() ... - return pool[0][2] FREE_ZVAL() - Clear memory @ pool[0][1] ALLOC_ZVAL() - Do we have a zval available? - return pool[0][3] or do we return pool[0][1] The problem I see with an array approach from an api perspective is simply when a bucket is free'd, in order to have efficient memory usage, we'd need a second level array scan for every ALLOC_ZVAL(). Perhaps a linked list would be a better choice for this, as we can just be smart about bucket access, and eliminate the need for a scan (could be possible I'm missing something?) I think I was misunderstood. Of course I would want a free list. Check out the objects_store code in ZE2. The idea is to have something similar. When we free allocated buckets we add them to a linked list. The linked list is inside the structure itself, i.e., when the bucket isn't used we can use its memory for the pointer to the next element. So allocation just takes the bucket out of the free list. So basically the bucket is a union between sizeof(zval) and sizeof(*) (or sizeof(int)). If it's still not clear I can explain it in a longer letter later on. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
