commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bur...@apache.org
Subject svn commit: r154073 - jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
Date Wed, 16 Feb 2005 19:31:07 GMT
Author: burton
Date: Wed Feb 16 11:31:06 2005
New Revision: 154073

URL: http://svn.apache.org/viewcvs?view=rev&rev=154073
Log:
moved TODOs to a dedicate source file

Modified:
    jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java

Modified: jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java?view=diff&r1=154072&r2=154073
==============================================================================
--- jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
(original)
+++ jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
Wed Feb 16 11:31:06 2005
@@ -19,26 +19,29 @@
 import java.util.*;
 
 /**
+ * <p>
  * Benchmark that allows cheap and lightweight "benchmarking" (go figure) of
  * arbitrary code.  All you have to do is call start() every time a method
  * starts which will then increment the benchmark and perform any operations
  * necessary to maintain the benchmark.  Just call complete() when your method
  * is done.  
  * 
+ * <p>
  * This class is lightweight (only requires a hashmap entry, and 32 bytes per
  * benchmark of storage with no external requirements.  This class is also
  * threadsafe so if you need to call this from multithreaded code to benchmark
  * then you'll be ok.
- * 
+ *
+ * <p>
  * The benchmark is maintained as number of starts and completes per minute.
  * This can be any type of operation you want.  Technically the interval can be
  * longer than a minute but we will end up with stale data.  That's the tradeoff
  * with this type of benchmark.  Its cheap and easy to maintain but anything
  * more than 60 seconds worth of data and you'll end up with a stale benchmark.
- * 
- * Internally we use an incremented value which is accumulated and reset ever 60
- * seconds.  When we reset the benchmark we reset the current value so that we
- * can start accumulating again.
+ *
+ * <p> Internally we use an incremented value which is accumulated and reset
+ * ever 60 seconds.  When we reset the benchmark we reset the current value so
+ * that we can start accumulating again.
  * 
  * <code>
  * 
@@ -64,41 +67,6 @@
  * @version $Id: Benchmark.java,v 1.3 2005/02/16 02:28:09 burton Exp $
  */
 public class Benchmark {
-
-    /*
-
-    TODO:
-
-    - Ability to enable logging with log4j and debug() so that during every
-      rotate of the benchmarks I will get a log.info() message.  These should be
-      log4j categories so that I can do benchmark.ksa.om.ArticlePeer.hasArticle
-      and then enable benchmarks via a log4j configurator.
-
-      - Potential bug.  If we don't log anything > 5 minutes the LAST benchmark
-      will be rotated.  I actually have to check if the last benchmark was more
-      than INTERVAL ago and if so then delete the last benchmark
-
-      - Potential bug.  When we don't call start/complete for a long period of
-        time we wouldn't ever log our status.
-
-    - It might actually be BETTER to combine the last benchmark with the current
-      benchmark but prorate the current value and then avg() them.  This would
-      give us a more realistic "ETA" style benchmark of current performance.
-      For stats which don't update very much or for 5 minute interval stats this
-      would be perfect.
-
-      - We're going to need a config file like log4j...
-      
-    */
-
-    //FIXME: how can we measure the TOTAL time we've spent between
-    //start/complete ??  This might be important because for tasks like SQL
-    //selects we'll need to time the duration we spend in the methods.  I'm not
-    //sure its even possible with the current API.  This actually doesn't make
-    //much sense in threadtime if you think about it.  For example 100 threads
-    //could be started which each take 60 seconds to finish.  If they all finish
-    //at the same time we would compute that 60000 seconds of machine time were
-    //used
     
     /**
      * How often should we maintain/reset the benchmark.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message