This is my biggest frustration with DBG right now, and has been for years. The profiler.

When will the profiler actually perform the full requirements of a profiler?

Currently it will tell you how much time a particular line of code spent during its (many) executions, but there is absolutely no way to tell where the executions were called from.

IMO, to be called a profiler, it needs to return a full execution profile for the code. It's all well and good if MyDB::query() took 60 seconds, but if the function is called from hundreds of places in your codebase, you need to know WHICH ONE took that long, not only that one of them did.

I've been a PHPEd subscriber since... 2004, I think. Before profiling was even added. This is the only thing that continues to make me angry when I need to use it.

So, what it comes down to is this:

I would be extremely happy to see two things added to DBG:

1. Full execution profiles
2. The ability to write the profile to a server-side file which can be loaded into the profiler view.

These two things are critical when trying to profile long-running server-side PHP applications.

If a decent Windows version of CacheGrind existed (WinCacheGrind isn't decent, isn't still in development, and isn't stable), I'd probably just use xdebug for this feature. I *hate* to have to run two separate debugger applications (which of course conflict with each other and require php.ini modifications every time you want to switch between them) when one should be able to do the job.

hmm, profiler was added in 2001, when I joined the team.




While this is realated to performance measurement, it has nothing to do with profiler. Absolutely.
The main profiler task is to answer the question "how fast your code works" regardless of the context. What you're trying to do is to find an answer to the question like "how fast your database works" depending on the query. At least it's a task for samplers or loggers.

I still have my CD copy of PhpEd 3.3 sitting here, released 3/15/2004 (not even the first release I used), and it has no profiler.





No, that's absolutely wrong. What I gave was an example. Your "profiler" can not tell me how fast my code works if it can't tell me how fast the function runs when given different inputs. All it gives is a very flawed average. If I'm trying to identify why the code takes 90 seconds to run when it's called with one set of parameters, and 1 second when called with a different set, the PHPEd profiler does absolutely nothing to assist that; It's just going to say that it took an average of 1.89 seconds, with a maximum of 90.

My background before PHP was C and C++. Code profiling is very old-hat in that environment, and any profiler worth its installation footprint will give you a full execution output. It's the *only* way to accurately measure performance because functions can perform very differently given different inputs.

You may think you know it better than me, who implemented the debugger and profiler in phped 3.0. Of course it's there in version 3.3 too. See Tools->Show Profiler.



Ok. There is nothing to dispute over. Php profiler implemented in PhpED is very similar to the profilers that you can find in Borland and Microsoft IDEs. So, it matches the standards, even though it can not help you with profiling mysql queries.

Hi dmitri, Hi Signe,

I understand that Dmitri is not very happy about the comment on profiler. But we don't blame you or Nuphere, we blame PHP tools in general (I have a Java background and there profiler give a lot more information).
I also agree with Signe. I am also very frustrated about the profiler limitation for the moment.

I think that Signe also need a complete call tree with cumulative time like already discuss here at the end of the post :
limiting-deep-for-profiling-t5988.html?highlight=profiling

to be able to see in his main script which part of it takes a lot of time (not only to see witch line in a subfile is consuming time).