Remote Profiling with D7 (NOT memory profiling, but timing…)

Question

We have one machine in-house that is 20 times slower starting our Delphi 7 app than any other machine.

We would like to get a performance profile (not memory profile) to locate where it's spending its time.

AQTime, which we own, we've discovered doesn't do remote profiling.

We'd prefer not to take the time to build up an entire D7 IDE development environment just so we can use AQTime to profile our app on this one in-house machine.

The code is a bit too complex for us to want to meter it ourselves.

Any suggestions on a profiler that will gather high level (procedure or line number) statistics remotely?

Answer 1

Why not install AQTime on the machine and use it as a standalone profiler? No need for an "entire D7 IDE development environment".

Answer 2

Take a look at SamplingProfiler. It doesn't do "remote" profiling, but it also doesn't require a development environment. It just needs to be able to launch the program to be profiled (so it has to run on the same machine) and the program has to have a .MAP file generated by the linker in the same folder as the .EXE. If this is in-house, that shouldn't be a problem for you.

And if you look at the helpfile, you'll even find ways to have it only profile certain sections of your program, which AQTime can't do. That helps if you know the issue is in one specific place, such as the startup code.

Answer 3

You can also try my free/open source sampling profiler: http://code.google.com/p/asmprofiler/wiki/AsmProfilerSamplingMode

(I get better results with it than with SamplingProfiler) It uses all kinds of Delphi debug symbols (.map, TD32, .jdbg, etc)

Answer 4

You can use our Open Source TSynLog class to add profiling to any application, not only on the developer computer.

It is not an automated profiler, as other tools: you'll have to modify your code. But it can be run on request remotely and even with no communication at all, even from the end customer side.

You add some profiling calls to some method code, then entering and leaving the methods will be logged into a text file. Then a supplied log viewer is available, and has some dedicated method to do the profiling, and identify the slow methods.

_{(source: synopse.info)}

The logging mechanism can be used to trace recursive calls. It can use an interface-based mechanism to log when you enter and leave any method:

procedure TMyDB.SQLExecute(const SQL: RawUTF8);
var ILog: ISynLog;
begin
  ILog := TSynLogDB.Enter(self,'SQLExecute');
  // do some stuff
  ILog.Log(sllInfo,'SQL=%',[SQL]);
end; // when you leave the method, it will write the corresponding event to the log

It will be logged as such:

20110325 19325801  +    MyDBUnit.TMyDB(004E11F4).SQLExecute
20110325 19325801 info   SQL=SELECT * FROM Table;
20110325 19325801  -    MyDBUnit.TMyDB(004E11F4).SQLExecute 00.000.507

Here the method name is set in the code ('SQLExecute'). But if you have an associated .map file, the logging mechanism is able to read this symbol information, and write the exact line number of the event. You can even use a highly compressed version of the .map file (900 KB .map -> 70 KB .mab, i.e. much better than zip or lzma), or embed its content to the executable at build time.

Adding profiling at method level is therefore just the matter of adding one line of code at the beginning of the method, as such:

procedure TMyDB.SQLExecute(const SQL: RawUTF8);
begin
  TSynLogDB.Enter;

  // do some stuff

end; // when you leave the method, it will write the corresponding event to the log

High-resolution timestamps are also logged on the file (here 00.000.507). With this, you'll be able to profile your application with data coming from the customer side, on its real computer. Via the Enter method (and its auto-Leave feature), you have all information needed for this.

By procedding steps by steps, you'll get very quickly to your application bottlenecks. And it would be possible to do the same on the end customer side, on request.

I used this on several applications, and found out very easily several bottlenecks, even on specific hardware, software and network configuration (you never know what your customers use), very easily.