Okay that's more like it, emalloc on top. That's what I would expect in the first place. And I guess Zeev is right that it doesn't really tell you anything expect from that PHP does its share of alloc/free, and then some.
- Stig On Mon, 2002-05-13 at 23:06, Rasmus Lerdorf wrote: > Well, zend_parse() is actually not always on top. I have run this thing > longer now and it currently looks like this: (reverse order) > > 001bdcd0 293 0.42199 init_op > 00156c08 306 0.440713 smart_str_appendl_ex > 0019b484 334 0.481039 php_strlcpy > 001db788 337 0.48536 _get_zval_ptr_ptr > 0015f2b4 341 0.491121 parse_iv2 > 001db198 347 0.499762 zend_pzval_unlock_func > 001cbf00 364 0.524246 zend_hash_clean > 0015ee18 392 0.564573 var_push > 001dbb88 396 0.570334 zend_assign_to_variable > 001c45d0 398 0.573214 _zval_copy_ctor > 001c3dfc 416 0.599139 zend_ptr_stack_n_push > 001bdaf0 432 0.622183 destroy_op_array > 001c3560 459 0.661069 zend_str_tolower > 0015701c 465 0.66971 smart_str_print_unsigned > 001b9970 465 0.66971 zendlex > 001b2440 467 0.672591 _erealloc > 001d45e4 473 0.681232 zend_fetch_property_address > 001c4970 497 0.715798 _zval_ptr_dtor_wrapper > 0015ef14 516 0.743162 process_nested_data > 001946c8 526 0.757565 xbuf_format_converter > 001b27fc 629 0.905909 _estrndup > 001db1fc 647 0.931834 zend_clean_garbage > 001cb9b8 686 0.988003 zend_hash_rehash > 001cc6cc 711 1.02401 zend_hash_copy > 001c45c0 764 1.10034 zval_add_ref > 001d398c 953 1.37255 zend_fetch_var_address > 001ca5f8 975 1.40423 _zend_is_inconsistent > 001cbda8 1046 1.50649 zend_hash_destroy > 001c443c 1235 1.77869 _zval_dtor > 001baf6c 1302 1.87519 _zval_ptr_dtor > 001db270 1419 2.0437 _get_zval_ptr > 0015dcb4 1464 2.10851 php_var_unserialize > 001ccae0 2460 3.54298 zend_hash_find > 001b3028 2917 4.20117 _mem_block_check > 001d4ca0 3931 5.66157 execute > 001ca85c 4438 6.39177 zend_hash_add_or_update > 001a56bc 4597 6.62077 zendparse > 001b21b8 4692 6.75759 _efree > 001cdaf8 5458 7.86082 zend_inline_hash_func > 001a9f4c 5501 7.92275 lex_scan > 001b1ea4 6321 9.10374 _emalloc > > > > On 13 May 2002, Stig S. Bakken wrote: > > > On Mon, 2002-05-13 at 17:53, Zeev Suraski wrote: > > > The link you specified doesn't work (it's .net)... Nice touch on their part > > > on having a page that doesn't render under IE :) > > > > > > Anyway, the important question is whether you're using it under Linux or > > > some other OS. Under Linux, unless it has some kernel module, it's going > > > to be horribly inaccurate. After finding this page, it does appear as if > > > it's using a kernel module. Congrats to Linux for finally having a usable > > > profiler! > > > > > > It's pretty consistent with the results I got using NuMega's profiler about > > > a year ago (I don't remember the exact numbers, but the functions are more > > > or less the same). > > > > Seeing that the single most time-consuming function is zend_parse, it > > would be interesting to see where the bottleneck moves when using > > ZendAccelerator or another caching product. Did you try that setup with > > NuMega's profiler? > > > > - Stig > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
