1

I am trying to speed up my app start-up time (currently ~5 seconds due to slow Guice binding), and when I run traceview I'm seeing pretty big variations (as high as 30%) in measurements from executions of the same code.

I would assume this is from garbage collection differences, but the time spent in startGC according to traceview is completely insignificant.

This is particularly aggravating because it's very difficult to determine what the effects were of my optimizations when the measurements are so variable.

Why does this happen? Is there any way to make the measurements more consistent?

Jeff Axelrod
  • 27,676
  • 31
  • 147
  • 246

3 Answers3

0

I suppose you are starting profiling from the code rather than turning it on manually? But anyway even if you use Debug.startMethodTracing and Debug.stopMethodTracing from a specific point of your code you will receive different measurments.

You can see here that Traceview disables the JIT and I believe some other optimizations so during profiling your code is executed slower than without it. Also your code performance depends on overall system load. If some other app is doing any heavy operation in background your code will execute longer. So you should definitely get results that a slightly different and so start-up time couldn't be a constant.

Generally it is not so important how long your method executes but how much CPU time it consumes comparing to other methods.

Andrei Mankevich
  • 2,253
  • 16
  • 15
  • I'm talking about measuring CPU time, which of course is the only metric traceview provides. I must have confused you with my mention of the five-second startup time (measured with a stopwatch without profiling enabled) as an introduction to the motivation for profiling in the first place. So how do I measure with reasonable consistency how much CPU time the startup consumes? And yes, I'm using `Debug.start/stopMethodTracing` – Jeff Axelrod Jul 15 '12 at 19:14
  • I don't think it is possible to achive more consistency than you already have. If your initialization process uses some IO functions for reading data it already wouldn't be consistant. Also I suppose your code is running in the separate thread so if it is running on uniprocessor system profiling results will depend on system thread scheduler because actually your code wouldn't be executed all this time continuously. I'm pretty sure it is not possible to get totally identical traces from different launches. – Andrei Mankevich Jul 15 '12 at 19:55
0

Sounds like measurement is not your ultimate goal. Your ultimate goal is to make it faster.

The way to do that is by finding what activities are accounting for a large fraction of time, so you can find a better way to do them. I said "finding", not "measuring", and I said "activities", not "routines".

To do this, it is only necessary to sample the program's state. Many profilers collect a large number of samples of the program's state, but then they all fall into the same logic - they summarize, on the theory that all you want is measurements, and you don't really care of what.

In fact, if rather than getting summaries you could examine some of the samples in detail, it would tell you a great deal more about how the program is spending its time.

What's more, if on as few as two(2) samples you could see the program pursuing some goal, and it was something you could improve significantly, you would see a significant speedup. This process can be repeated several times, and that's how you can really optimize it.

The process is explained in more detail here, and there's a use case here.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • Interesting, but unless I'm missing something, it doesn't help to answer the question. Traceview already gives a completely deterministic method call count and hierarchy. – Jeff Axelrod Jul 16 '12 at 16:23
  • @Jeff: 1) Don't expect consistency of timing measurements. There are too many uncontrollable factors, and it doesn't matter anyway. 2) Regarding the call count and hierarchy, check the issues [*here*](http://stackoverflow.com/a/1779343/23771). It can seem that it is telling you everything you need to know, but it is not. – Mike Dunlavey Jul 16 '12 at 16:39
0

If you are doing any network related activity on startup then this tool can help you understand what is happening and how you might be able to optimize connections and caching. http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312

Rod Burns
  • 2,104
  • 13
  • 24