When you don't select Deeptrace rulesets, CodeTrack will still provide a timeline in the output. The difference is that this is a virtual timeline. It is constructed based on the sampled stacks.
You can recognize the virtual timeline by the orange color scheme and by the warning in the top right corner. It is important to know that a timeline is virtual because it has a few consequences you need to take in account when analyzing your data.

How it works

There is a slight but important difference between tracing and sampling mode, so I'll explain them seperately.

• Sampling

  
  

  Sampling means that the profiler will periodically freeze all managed threads and during each freeze a stack snapshot is taken for each thread and stored with a timestamp.
  When constructing the timeline, the only thing we know for sure is which methods were active at the moment of the snapshot. All of these snapshots are put next to each other and if a method is the same as in the previous snapshot, it is glued to the previous one.
  This has some important consequences you need to keep in mind while looking at your virtual timeline:

  • It might very well be that in realtity a method's duration was much shorter
  • Glued samples might be incorrect, so a method spanning more than one sample might in reality be alternated by other methods
  • A single method might in reality be more than one, in other words: the method count might be incorrect.
  • Probably a lot of method calls are missing
  The moment at which a snapshot is taken, is marked at the top of every thread by means of a little green tick. If you zoom in really hard you can even see the suspension induced by freezing the thread:
  




• Tracing

  
  

  Tracing works similar compared to sampling, but every time a method starts or ends, the count is updated and the duration is stored. Every time a method event occurs and 100ms has passed, a snapshot is stored with a timestamp. As a consequence, this snapshot contains all methods called during this timeframe, their count and their total duration.
  While more accurate than sampling, this still has some important consequences you need to keep in mind while looking at your virtual timeline:

  • The duration of a method is correct, but the count is not (for simplicity, multiple calls are grouped together into 1). However the real call count is displayed on each virtual block.
  • The position is not exact: the method(s) definitely occured during the 100 ms sample range, but we don't know the exact position or the order in which they occured.
  • If a method is started but not ended in a particular snapshot, it is automatically glued to the next one. In this case this is correct.
  • No method calls are missing (although in the timeline some of them might be grouped into 1 block)
  The moment at which a snapshot is taken, is marked at the top of every thread by means of a little green tick. This gives you an idea of the exact timeframe in which the presented method calls occur (even though their position is not exact, we know for sure they occur between the green ticks):
  

• Mixed mode with DeepTrace

  
  

  As you can read in Profiling modes, it is possible to combine Deeptrace mode with regular tracing. In that case, the resulting timeline will contain virtual items (tracing) combined with real items (Deeptracing) of which the exact start and stop time is known.

What's the use ?

If the virtual timeline is not exact, then why is it provided anyway?
First of all, it gives you an idea of what is going on during the lifetime of your application. Next to giving you information about the total performance of your method calls, you can now also get a rough idea about the chronological order and also see if at particular moments in time methods tend to take longer.
Another, more important, reason is that this virtual timeline facilitates the rescope feature (more info here). Based on the virtual timeline you can specify ranges to rescope all the other views, so you can for instance compare 2 separate moments in time.