Search the Community

https://en.delphipraxis.net/search/?&q=profilers&search_and_or=or&sortby=relevancy https://www.google.com/search?q=delphi+profiling A few versions (around XE) had a limited version of AQTime bundled in. Apart from that it's hardly their area of expertise and it's been ages since they had resources to spare for anything but the core product. That will never happen. There's simply no benefit for them in open sourcing it, only expense, and it probably also contains code that can't be open sourced.

Hi All What are the performance profilers for Delphi 12? Under Delphi 10.4 I use AQTime. But it looks like AQTime with Delphi 12 support hasn't been released yet.

Yes it does - but map2pdb just produces the pdb files required by the profilers. Profilers that works with pdb files includes Intel VTune and AMD μProf. I believe μProf works with both Intel and AMD processors while VTune only works with Intel processors but use the one that matches your processor to get the most precise results. I use VTune myself. Ask if you need instructions on how to get started. The process is very easy once you know how to do it but it can be challenging to get to that point 🙂

The profilers for 64 bit applications developed with Delphi XE2 up to Delphi 12 and for 32 bit applications developed with Delphi 5 up to Delphi 12 are released. ProDelphi mesures 32 bit applications, ProDelphi64 measures 64 bit applications. Prodelphi6432 measures both. All ProDelphi versions measure how many CPU-cycles a method (procedure or function) uses during execution. Measurement is independent from CPU mode at execution time (normal, boost or power save mode). Even a mode change during execution does not matter! After measurement the cycles are converted into time units by the viewer considering the CPU speed. UI languages selectable: English, German, Dutch, French, Italian Downloads of the limited Freeware Version measuring 20 methods are available at https://www.prodelphi.de. The professional version can measure up to 65500 methods.

Like @Anders Melander said, the Task Manager is not the right instrument to measure the performance of your application. One of the simple way is to measure the time the your software needs to do some tasks. Compare with old systems (if you can) or analyze with the datas that you histrical have. If you really use a bunch of threads you are not able to "consume" all processor power. You can measure performance datas with "profilers" or simply usingn "time base view" with TStopWatch (from System.Diagnostics) for primitive analyses.

As Cristian says, use a profiler! I have been happy using NexusQA profiler for many years. There are other profilers out there, some free. But, my time is worth enough that spending a little money to get a commercial product was well worth it to me. There are profiler discussions elsewhere on the forum here. Avoid AQTime. It's a good company selling an archaic, inferior (and pretty-much unsupported in my experience) Delphi Profiler. Also, evaluate your SQL. Look at the execution plan, consider stored procedures, etc. But, don't do anything until you know where your bottlenecks are in code or SQL.

This is where I am confused (and I have read all the existing documentation). You recommend configuring a tool in Delphi with these parameters: -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001 When I do this, it will parse my map file correctly, but it won't load any source lines regardless of the segments that I include. If I I change to something like this: -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001;0003;0004 It also doesn't load any source lines. I checked this within the debugger directly. It enumerates the files correctly, it just doesn't consume them into the FSourceLines collection. Is my syntax correct or am I supposed to be doing this: -debug -v -pause -bind:$EXENAME $PATH($EXENAME)$NAMEONLY($EXENAME).map -include:0001;0002;* so I am indicating both filenames and segments to include? I would be happy to assist in any way I can. I think it's a great tool and would love to do an Embarcadero Coderage MVP session on how to use some of the industry standard profilers with your utility in the future, if that's okay. I noticed other people have encountered the same issue with consuming overlapping segments. In my case I modified the code to skip the overlapping segments instead of raising an exception and stopping. For example, Delphi emitted the map file segments as: Start Length Name Class 0001:0000000000401000 006CD7B8H .text CODE 0002:0000000000ACF000 000A9208H .data DATA 0003:0000000000B79000 00011F20H .bss BSS 0004:0000000000400000 00008260H .tls TLS 0005:0000000000BDE000 0004FF5CH .pdata PDATA TDebugInfoSegment.CheckOverlap subsequently raised an exception: Project map2pdb.exe raised exception class Exception with message 'Overlapping segments: .tls [0004:0000000000400000] and .text [0001:0000000000401000]'.

Profilers measure application execution. Two main types are Sampling and Instrumenting profilers. You run the application and the profiler measures times for code to complete. It sounds like what you want is some sort of AI to read/parse your code and suggest improvements. You could try feeding pieces to ChatGPT and see how well that performs... Or, perhaps you want a static code analyzer, like Pascal Analyzer from Peganza....https://www.peganza.com/products_pal.html it will parse your code and provide reports of things that could be improved. (They offer a free, limited feature version to try....Pascal Analyzer Lite: https://www.peganza.com/download.html)

For profilers, we use NexsDb's: https://www.nexusdb.com/support/index.php?q=node/27156. It's a wonderful product and has helped us a lot. We suggest you avoid SmartBear AQTime. It felt it was designed for C/C++ and that Delphi was added as an afterthought.

If one starts with good algorithm then the only thing that works for me is to do profiling (without instrumentation). I've had good luck with (the free) Vtune Profiler from Intel. Attached is a picture showing comparison of Delphi and Cpp for prime sieving console application on Windows. This sample uses the Fastmm5, but the differences in cache misses are not that different than the Delphi shipping version of Fastmm. I should also note that the Delphi implementation needs more work (in the algorithm more than anything else), but this might give you an idea of where to look for performance improvement. Also, one needs to jump through some hoops to find the actual line in Delphi code where bottlenecks appear (unlike some of the profilers mentioned above which can zero in to function).

François, for something like this you probably don't need a profiler at all. Especially not an instrumenting profiler (more on that later). What I always do, before resorting to profilers, is to simply run the code in the IDE and pause the execution in the debugger when the time critical code is executing. Statistics dictate that the current call stack will show you exactly where your hot spot is. Repeat a few times to verify. Basically this is the same approach a sampling profiler uses. The problem with instrumenting profilers is that the overhead of the instrumentation code affect the timing results so much that you can't really rely on it. They're great at determining call graphs and identifying the relative call frequency of different methods, but in my experience you can't use the timing for much.

I used it a couple of times and it worked well as far as instrumental profilers go.

I don't know about VTune per se, but for what i do understand and know, pdb file can be dependent from the EXE and yet debuggers/profilers should be able to recognize them, my try in the past was a fail, yet then i managed to use MAP file parser from EurekaLog and managed to (in very simplified way) add one stream to the MSF file and generate simple/skeleton pdb file, just the one and back then Process Explorer started to show the thread stack address translated into functions right, tested successfully also on a debugger, later it did fail miserable when the table was big, not small, i really can't remember the details now. Anyway, @Anders Melander , from what i recall i didn't touch the exe it was the pdb who should matched the TimeStamp in the PE header of the exe, and that it is. Also googling now, i found this http://www.debuginfo.com/articles/debuginfomatch.html which i think does show that IMAGE_OPTIONAL_HEADER is irrelevant to use external pdb files. "DBG files use a similar approach, where the role of the unique identifier is assigned to the executable’s timestamp (which is stored in the executable’s file header, IMAGE_FILE_HEADER.TimeDateStamp). The same timestamp is stored in the header of the DBG file (IMAGE_SEPARATE_DEBUG_HEADER.TimeDateStamp). When a debugger checks whether a DBG file matches the executable, it reads the timestamp from the DBG file and compares it with the timestamp stored in the executable. If timestamps are not equal, the DBG file is considered unmatched. In addition, Visual Studio debuggers also check for presence of IMAGE_FILE_DEBUG_STRIPPED flag in Characteristics field of the executable’s file header (IMAGE_FILE_HEADER.Characteristics), and refuse to load the DBG file if the flag is not set (actually, they check the flag first and do not look for DBG file at all if the flag is not set). WinDbg debugger does not check this flag in the default configuration, and uses only timestamp to verify that the DBG file is matched.|" And good luck.

The main reason is in the very first sentence of my previous post. Also as you are so into benchmarking I suggest you make yourself familiar with profilers so you don't have to guess or ask others what is taking time as you can very well see for yourself.

I'd rather describe it again. I was dealing with a bulk write to a JSON file. Previously, I wrote down each item separately. It was unbearable. The acceleration was enormous. From a few seconds to "nothing". All my forms have been closing for a very long time. 5 -> 10 sec. That's when I realized it was caused by an incorrect entry in JSON. I go through the whole form and write to JSON for the affected components. Now only a small adjustment in one place. Forms close immediately. This is unwanted optimization. Maybe I could find profilers. I only mentioned it for variety. I'm not a programmer. I'm just playing with him

You're the only one talking about timers, but even if you used a grandfather clock the method would work. If you break the application at random you will have 50% higher likelihood of hitting lineB than lineA and each time you do this the likelihood increases. This is exactly how a sampling profiler works. Are you saying sampling profilers are a hoax?

Another option is some kind of binary search when one comments out most of the code until things are fast and then uncomments pieces to track what exactly causes slowdown. This method is especially useful when there is some piece which runs for a small time but executes very frequently. Profilers and timers won't help much here.

I have a collection of these profilers. I've never worked with them! For inspiration. .

In my experience you get what you pay for. None of the free profilers has ever worked satisfactory for me. I would recommend AQTime or VTune but they are both a bit expensive. I prefer VTune but as it doesn't support Delphi debug info it's only suitable for asm level profiling. It's excellent for that though.

> However, if you need information (for example, perhaps you work on low-level code for profilers or debuggers, or have code for stack manipulation, inline assembly and naked functions, or similar) feel free to contact us. Inquiring minds want to know! 🙂

Version 37.0 of ProDelphi and ProDelphi64, the high accuracy profilers for Delphi are released now. New in this version is the support for Delphi 10.3 Rio. ProDelphi measures 32 bit applications and supports Delphi 5 .. 10.3 ProDelphi64 measures 64 bit applications and supports Delphi XE2 .. 10.3 Information about ProDelphi: http://www.prodelphi.de