Changes between Version 2 and Version 3 of GROUP_APP_PERFORMANCE_R1

Timestamp:

05/19/09 19:27:18 (16 years ago)

Author:

gogov

Comment:

--

GROUP_APP_PERFORMANCE_R1

@@ -17 +17 @@
   * Structure the profiler report by the natural stack trace execution tree-like structure. This means that at the top of the tree there should be the main() run method of FakeAuthorMain for instance with total time consumption of 100%. Lower there should be methods which are directly invoked from main() and the sum of their total time consumption should be 100%, etc.
   * This profiler is intended to locate higher level methods which consume too much time and/or are called too many times, so we can optimize them. Locating that lowest level methods like native library file system IO calls are called lots of times doesn't help much because we can't do much to optimize such cases, but finding out that ReflectionUtil.findMethodAnnotation() consumes much time led to a big startup performance optimization before.
+  * If other useful features come up in mind and can be implemented in time, implement them.
   * Provide a report with the described results in an output plain-text file.
-  * Providing the functionality described above is generally done in two ways -- by actually measuring real time execution and by statistically measuring time consumption. The second is done by doing snapshots of the program's state at a given interval and gathering statistics about current methods in all alive threads. First one seems to be too slow and me and Milo think that the second gives a good enough accuracy of the result, so use the second approach.
+  * Providing the functionality described above is generally done in two ways -- by actually measuring real execution time and by statistically measuring time consumption. The second is done by doing snapshots of the program's state at a given interval and gathering statistics about current methods in all alive threads. First one seems to be too slow and me and Milo think that the second gives a good enough accuracy of the result, so use the second approach.
 
  * If a good enough profiler is proposed and there's no longer a need for a customer profiler, drop it and use the existing one.
@@ -24 +25 @@
  * Use the (custom or already-existing) profiler to identify low performance spots which could be optimized.
 
- * Optimize these spots by either low-level hacks or by proposing new design which could be implemented in time.
+ * Optimize these spots by either doing quick low-level hacks or by proposing new design which could be implemented in time.
 
 == Task result ==
@@ -46 +47 @@
 
 = Implementation =
-^(Describe and link the implementation results here (from the wiki or the repository).)^
+ * '''hprof''''s file format can be used as a base for the output format of our custom profiler.
+ * use Thread.getAllStackTraces() and then build a tree.
 
 = Testing =