Ideally, you should profile as close to the target you care about as possible. For example, a good profiling case is testing your game in standalone form on the target hardware
with built lightmaps.
For good profiling, it is best to setup a reproducible case isolated from things that can add noise to the results. Even the editor adds some noise (e.g. an open Content Browser can add rendering cost)
so it is better to profile in a game directly. In some cases, it might be even useful to change code (e.g. to disable random number generators). The Pause command or Slomo 0.001 can be very useful
to make things more stable.
Measure a few times to know how accurate your profiling is. Stat commands such as stat unit and stat fps give you some numbers to start with. Accurate profiling should be done in milliseconds (ms),
not frames per second (fps). You easily can convert between the numbers but relative improvements have little meaning when measured in fps. When talking about individual features, we only speak about
milliseconds as it is not measuring the frame.
If you see a limit on 30 fps (~33.3ms) or 60 fps (~16.6ms), you likely have VSync enabled. For more accurate timing, it is better if you profile without it.
Do not expect an extremely high frame rate with a very simple scene. Many design choices pay off for complex scenes (e.g. deferred rendering) but have a higher base cost. You also might bump into a
frame rate limiter. If needed, such things can be adjusted (e.g. t.MaxFPS, r.VSync).