viporeo.blogg.se

1. #Jprofiler limit hotspots how to#
2. #Jprofiler limit hotspots mac os x#
3. #Jprofiler limit hotspots full#
4. #Jprofiler limit hotspots code#

If you run the benchmark on another system, please send me the results or post them in the comments.

#Jprofiler limit hotspots mac os x#

The benchmarks will be reported on three different systems:Ī) MacPro, Mac OS X 10.4.9, 2x Intel Xeon 5160 (dual core 3 ghz), 8G RAM, JDK 1.5.0_07ī) MacPro, Windows XP SP2, 2x Intel Xeon 5160 (dual core 3 ghz), 8G RAM, JDK 1.5.0_11 + JDK 1.6.0 + JRockit 5.0 R27.2ī) Dell 1850, 2x Intel Xeon 2.8 ghz (1st gen dual core, hyperthreading enabled), 4G RAM, JDK 1.5.0_11, JDK 1.6.0

#Jprofiler limit hotspots full#

This should reflect what would be required to do Monte Carlo simulations or full solution space searches. This should reflect the worst case scenario for a poker server that is trying to serve games to users.Ģ) Evaluate random hands with random boards. The two benchmarks I produced to test the poker library were the following:ġ) Run an entire 10 hand Texas Hold’em poker game from beginning to end with no one folding and determine a winner. So the first stage of any optimization project is to create benchmarks that accurately reflect the usage of the system in the real world - with some nod to the worst case scenario. Some of my findings give insight into what kinds of things are optimized in JDK 1.6 vs JDK 1.5 and how things vary between Mac OS X, Windows, and Linux. I am trying to pinpoint which getDerivedUniqueId() is causing the performance degradation.Last night I decided to revive my poker hand evaluator library and look at it from a performance perspective and do some optimizations if need be. It eventually calls one of 150 getDerivedUniqueId(). Secondly, when isCollectMetrics is true, the jprofiler call tree I expect would start with startProfiling() and end at stopProfiling(). The CPU tree seems not to take into account the triggers. My expectation is that when I JProfile the application (both sampling and full instrumentation) with the below configured triggers, if boolean isCollectMetrics is false, I should see 100% or 99.9% of cpu in filtered classes.

#Jprofiler limit hotspots code#

In the code below, I set triggers as shown after the code.

#Jprofiler limit hotspots how to#

I am likely not clear on how to use triggers. Thank you Ingo Kegel for your assistance. Hence, I need to turn on full instrumentation ONLY after getDerivedUniqueId() is invoked and pause profiling when getDerivedUniqueId() is exited. When I run it in full instrumentation, I've waited 3 hours and it still hasn't completed.

The reason I need to limit the recording to just this method is: When running in 5ms sampling mode, the application completes in 10 minutes. Hence, even if I figure out how to correctly enable the trigger, the added overhead would seem to render it ineffective. It seems the trigger is adding a giant amount of overhead on top of the overhead.

Worse yet, even with 5ms sampling, this trigger increased the previous running time from 10 minutes to "I terminated after 3 hours of running".

I was expecting to only see everything below markForDeletion(), but I saw everything up to but not INCLUDING getDerivedUniqueId(), which is the opposite of my intended goal.