[news.eclipse.tools.hyades] Re: Extreme performance degradation while pr

["Dave Kelsey" <dkelsey@xxxxxxxxxxxxxxxxx>]

Curt, thanks for the reply. I am trying out the write to file route. I see
that there are
some profile options for standalone mode, but not all the options are
documented
in the online help that get's installed with the plugins.

Is there an upto date document on these options ? The options I see listed
are

<option key="CLASS_LOAD_DETAILS" value="false"/>
<option key="METHOD_DETAILS" value="false"/>
<option key="COLLATION_VALUES" value="false"/>
<option key="CONTEXT_FLOW" value="false"/>
<option key="FILTERS" value="true"/>
<option key="TRACK_GC_EVENT_TYPES" value="frees"/>
<option key="ID_STYLE" value="static"/>
<option key="OBJ_REF_MODE" value="filterOwner"/>
<option key="METHOD_COUNTS" value="false"/>
<option key="OBJ_ALLOC_IS_ARRAY" value="true"/>
<option key="OPTIONS" value="true"/>
<option key="STACK_INFORMATION" value="contiguous"/>
<option key="TRACE_MODE" value="full"/>
<option key="TICKET" value="true"/>
<option key="TIMESTAMPS" value="true"/>
<option key="TRACE_IDREFS" value="false"/>
<option key="UNREFERENCED_SYMBOLS" value="false"/>
<option key="THREAD_CPU_TIME" value="false"/>
<option key="HEAP_INFO_FILE_PREFIX" value="optHeap"/>
<option key="MONITOR_MODE" value="none"/>
<option key="EXTENSION_LIBRARY" value=""/>

(some of these are documented and some aren't)

Many thanks
Dave Kelsey


<curtispd@xxxxxxxxxx> wrote in message news:cer7n0$i1e$1@xxxxxxxxxxxxxx
> 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