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,
I did a quick little profile of a lightly hit PHP server running a variety
of PHP apps such as IMP, Gallery and a couple of small MySQL-driven apps.
A semi-representative tiny snapshot of what I would consider normal usage
of PHP. I threw oprofile at it (oprofile.sourceforge.org) and here are
We already tried our best to optimize most of the functions that show up in
profiling. Not surprisingly, they are mostly the infrastructure functions...
What profiler are you using? If it's under Linux, chances are it's
*extremely* inaccurate. Profiling under Linux is horrible.
Zeev
At
I did specify the profiler on line 4 of the message. And it is a pretty
good one actually.
On Mon, 13 May 2002, Zeev Suraski wrote:
We already tried our best to optimize most of the functions that show up in
profiling. Not surprisingly, they are mostly the infrastructure functions...
What
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
oprofile only works under Linux and it is driven by a kernel module.
On Mon, 13 May 2002, 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
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
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.440713smart_str_appendl_ex
0019b484 334 0.481039php_strlcpy
001db788 337 0.48536
At 23:59 13/05/2002, Stig S. Bakken wrote:
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?
It still stays in the
