[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.hyades] Re: Extreme performance degradation while profiling

Hi Dave,

This is a good question. I'm guessing the reason for this extreme 
performance loss is because of the vast amounts of data that have to be 
collected and processed. Consider the case where you have many very small 
and fast methods that are called a very large number of times. In order to 
collect execution data, the data collector will send a record of every 
single method entry and exit, along with a timestamp that we use to 
calculate times.

I have a few suggestions for dealing with this:

1. The first one is easy and you suggested it; profile to a file. This 
will essentially redirect the raw data coming in to a file without 
processing it at all. The contents stored will be zip compressed; so you 
'll be able to judge by the size of this file how much data is coming in. 
Because the parsing of the data is much slower than the generating on the 
data collection side, it shouldn't take as long. Then you would import the 
file. Rather than letting it grind all night while you're asleep, you can 
tell it to import, say, the first quarter of the file. If the operation 
has different phases; you may be able to pick out each phase and look at 
them separately. Along the same lines, under the Profiling tab in the 
launch configuration dialog, there is a Limits tab. This will allow you to 
set a limit after which no more data will be collected, if you want to 
look at the first part of the operation. In addition, you can manually 
start and pause monitoring while the operation is running, say, if you 
want to start collecting at a certain point in the operation.

2. Narrow down the filtering to, say, filter out certain methods. If there 
is a small, fast method that is called millions of times, you can put in a 
filter on this specific method. Note, the first filter that matches will 
be applied, starting from the top. While you'll no longer get data about 
this method, you can still look at cumulative times of the caller to get 
meaningful times. Base time means time strictly inside the method, and 
cumulative also includes any method that are called within this method. In 
order to identify which methods might be culprits, you might want to 
profile the very start of the operation and looking at the method 
statistics; sort by one of the time columns.

Hope this helps.

Curt