Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="info"><ac:parameter ac:name="title">New Proposal Template</ac:parameter><ac:rich-text-body>
<p>This page has been created from a template that uses "zones." To proceed:</p>

<li>Edit the page</li>
<li>Replace sample content within each zone-data tag</li>
<li>Remove this notice</li>
<li>Save the page</li>
<li>When you are ready for review, remove the <ac:emoticon ac:name="warning" /> Under Construction notice</li>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Under Construction</ac:parameter><ac:rich-text-body>
<p>This proposal is under construction and is not ready for review.</p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Stopwatch Component Proposal

Proposed Component Name Zend_Stopwatch
Developer Notes
Proposers Matthew Ratzloff
Revision 0.1 - 10 April 2007: Just throwing up a page to get the idea out there. (wiki revision: 6)

Table of Contents

1. Overview

Zend_Stopwatch is a very simple class for timing events. It can be used for time-sensitive operations, benchmarking the speed of components, etc. At one point or another everyone needs something like this.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.

  • This component will correctly reads a developers mind for intent and generate the right configuration file.
  • The generated config file will not support XML, but will provide an extension point in the API.
  • This component will use no more memory than twice the size of all data it contains.
  • This component will include a factory method.
  • This component will not allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
  • This component will only generate data exports strictly complying with RFC 12345.
  • This component will validate input data against formats supported by ZF component Foo.
  • This component will not save any data using Zend_Cache or the filesystem. All transient data will be saved using Zend_Session.

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

The component is instantiated with a mind-link that ...

6. Milestones / Tasks

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Stopwatch

8. Use Cases


... (see good use cases book)

9. Class Skeletons



proposals proposals Delete
zend_stopwatch zend_stopwatch Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 10, 2007

    <p>Hey Matthew,</p>

    <p>At a first glance, I think this might serve well as a sub package of Zend_Debug, eg Zend_Debug_Stopwatch? Benchmarking the speed of components, etc is usually only required in debugging/testing mode.</p>

    1. Apr 11, 2007

      <p>Hi Andries,</p>

      <p>Yep, I've considered that, but I ultimately decided against it. Stopwatches have other uses, as well.</p>

      <p>For example, say you are running a potentially long task. You estimate (based on current server load, etc.) it will require either a short or long amount of time. If it's short, you want to return the data within the same request. Otherwise, you want to add the task to a queue handled by a separate process, spawn an independent process to do the task, and update the client asynchronously.</p>

      <p>However, since it is only an estimate, you want to ensure that short tasks do not take longer than a certain fixed number of seconds (otherwise, users will say the system is unresponsive). By using a stopwatch, you can poll the elapsed time every now and then and if it's greater than a fixed number and you have a certain percentage of the task remaining, you can serialize the task as is and add it to the queue.</p>

      <p>As another example, say you have a report generator. It's slow in some areas, but in others it's fine. Fixing the slow bits may be more trouble than it's worth, so you time each part within the task and store the different values in a database. A couple weeks later, you can look at real usage data and determine if usage of that particular block of code, and how long it takes in relation to the overall request, justifies the hassle of streamlining it.</p>

      <p>One final example is an open-source application. Let's say it has a component that can either do its work natively (in PHP) or through an PHP extension. Perhaps the author can time the native code on the user's system and, if the system is performing too slowly, he can recommend (via a notification on a control panel) that the user installs the extension. "Such-and-such process takes on average 3.42 seconds per request. Consider installing the XYZ extension instead."</p>

      <p>Of course, these aren't typical use cases. The primary use for this class is simple benchmarking. But my point is that not all timing is done while debugging or testing. <code>Zend_Benchmark_Stopwatch</code> would be appropriate, but there's no <code>Zend_Benchmark</code> and no plans for any such component. <code>Zend_Stopwatch</code> seems appropriate to me.</p>

  2. May 07, 2007


    <p>I have also considered this mostly for benchmarking. I was talked out of it and pointed towards xdebug instead. Having used xdebug i still think this functionality would be usefull because of its simplicity. </p>

    <p>I suggest adding "lap time" functionality. Creating a function like mark() that would add the current time to an array and continue timing. The full stack of timing points; start, marks and stop could then be retrieved. The mark function could use information from debug_backtrace to distinguish timing points, or the user could name each point explicitly e.g. mark($name).<br />
    This would enable easy timing of multiple code blocks. </p>

    <p>Note: The mark functionality may make the stop function superfluous.</p>

  3. Feb 29, 2008

    <p>I'd propose some function to pretty-print result, because that's what usually people do, i.e.:</p>

    <p>print "My benchmark took $stopwatch time\n";</p>

    <p>Also, I see in the code that getElapsedSeconds() always calculates time relative to _getTime() which is essentially microtime(). It doesn't sound right when the watch is stopped. </p>

    <p>Also, I think having just one start and stop time is not enough if you want to time multiple intervals - it's better to have current interval start & stop and accumulated time. </p>