Re: Benchmark_Memory

I realize this is all very confused. Benchmark should provide some tools to observe, store, analyze and report resources comsumption from scripts. The intention is almost to compare different solutions in order to choose the best. "Best" can have different meanings depending on the application, as an example, php could be used in a washing-machine whose optima differ from a web application. *observe* Taking some "snap" of the process state. A snap is indexed by where it is taken, some point in the script reached during the execution. A point can be reached several time, so a snap also depends on some time-point. The state reports some data about what the script uses there and at this time: * most simple is null , means "we're here" , it's a hit counter (Profiler does it) * existing is elapsed time * elias propose an extension to memory usage * I was working on more as http://php.net/manual/en/function.getrusage.php does *store* That can be done direct by the script as current Benchmark, it could be just transmited and stored elsewhere (then also analyzed and reported) as I propose thru some socket. Observe, taking a snap cannot be avoided, but a deported processing of them avoids any more pollution of the observed process. Here, store means registering the snap, not necessarly storing it physically. If you run some profiler, it could be enough to cumulate some snap data, for example. *analyze* The snaps only produce some instantaneous image of the process. You generally want some "cumul" of the resources usage. This cumul is done over some space (script location) and time (order) of the snaps. * Benchmark's basic Timer only manage the location aspect as a "Mark" and the order as some increment. * Benchmark's profiler makes some "sectioning", * instead of just saying a location, it tells : I enter "here", I leave "here". * I was proposing to do some recursive sectionning. Anyway, sectionning uses the point analyze, a section is defined by enter/leave points. (stay ?) Cumulate means generally add some resource consumption * (snap after) - (snap before) as does basic Timer with elapsed time between a mark and the next. * A hit counter just say +1 * cumulate them as does Profiler. We did for pear's memory a cumul over sections with recursive sub-sectionning (class/method) * elias's proposal furnished some other cumul for memory, it's taking the peak as: max( was , is) * I proposed some universal / tunable but really discutable mechanism. *report* Outputing some tables , eventually recursive. To conclude, I know, there's plenty of tools to do what Benchmark should do. Its intention is to furnish some light tools: * only needing basic direct stuffs as any can get by pear * polluting the observed process a minimum. * easy to implement and run ... some KISS Practically, I have a few crash tests of several aspects of it, I look forward to organize and publish them. So I'm open to any collaboration about it within PEAR. Not sure that makes it all less confused :) -- toggg