Leaderboard

I have just finished making the stand alone GExperts Grep to really be stand alone, that is: It no longer needs the GExperts DLL but contains all the functionality in one executable. It has also been compiled with Delphi 11 Alexandria so it should be per monitor DPI aware. Another feature is the ability to integrate itself into the Windows Explorer popup menu. ... read on in the blog post

@Anders Melander I've installed the VTune Profiler 2022.1.0/621966 and loaded an exe with a 31MB pdb and the hotspot analysis took about a minute. I think this was way slower back in the days you wrote the converter. Give it a try on an other machine.

I'm using the latest vtune and didn't need to do anything with msdia140 and it all works perfectly.

Have a look at this: In addition to SAX parsers you may want to consider XmlLite. XMLLite is a good alternative to SAX on Windows. See the note about push and pull parsers. Similar speed and much easier to program with. And there is a Delphi wrapper (just a single unit to add to your project). In my experience XMLLite was very fast. Microsoft is using XMLLite to parse SVG files.

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

Understandable. I would do the same. GPX format is ideal for SAX parser. Avoiding allocations of thousands of XML nodes would be my best bet for optimization.

works fine for me!

Ctrl+Shift+Number to place a bookmark and Ctrl+Number to go to bookmark is a bit faster. I am using AutoHotKey, which allows to remap pressed keys, so I have created a simple script, which remaps Ctrl+Shift+Number and Ctrl+Number to its Ctrl+K/Ctrl+Q counterparts. If you want to try, I have attached this script; it should be put in AutoHotkey.ahk. This works for "IDE classic" key mapping in Delphi. Bookmarks.txt

Storing an interface in a pointer stinks right from the beginning.

If you have GExperts installed, you could use the "ExpertManager" to re-register the MMX dll (or just use RegEdit to do it manually)

For those following this thread:

I tried NQS for a while. The UI is very confusing to me. It is 80s but I don't mind that much; what I don't get is how you load the projects and profile them. Even when you launch it from inside Delphi, it doesn't work smoothly. I found it very cumbersome. The only other reliable and affordable solution I found is ProDelphi. I haven't tried the x64 version but the x32 works nicely. The only downside is that it alters the source code during what they call instrumentation. But it cleans the sources after that perfectly. And they are very responsive with support.

I'm once again in need of a good 64-bit profiler so I've been looking into what would be needed in order to generate PDB files from whatever Delphi can produce. First of all it seems the only good debug info source on the Delphi side is the MAP file and the format of that seems a bit unstable. However since it's a text file it should be easy to adapt to any changes in it. Then there's the PDB file format. The only good and reliable documentation of that appears to be what the LLVM project has produced. Microsoft at one time published some of their source code for dealing with PDB files but since then the repository appears to have gone into limbo and they have not kept it up to date like they said they would. Anyway, in short, a PDB file is a MSF container file consisting of a number of streams containing the different debug info in CodeView format. The MSF format is pretty simple and since I only need to produce PDBs I don't need to bother about decoding MSF files. That leaves the PDB CodeView streams. Thanks to the LLVM documentation their format are known. However, after reading the LLVM source, it has become clear that it would be a huge task to implement all the different stream formats and all the different data types. I guess one could get by with a subset but it doesn't really seems worth the effort to create something that only works sometimes. The biggest problem however is that I would be implementing something based on a port of a third party's interpretation of Microsoft's old (and by now out of date) source. PDB is an internal VS format and Microsoft has stated that it can, and mostly will, change with each new version of VS. For this reason they provide the Debug Interface Access API for those that need to read PDB files. Unfortunately there's no (known) corresponding API to write PDB files. PDB support is important for the LLVM project (they too would like VTune to work with their output ) so they appear to be trying to keep up with the PDB changes and since they obviously have more resources for that task than I do I've decided to aim for a solution that piggybacks on their work instead of rolling my own. The solution I'm going to try is to parse the MAP file in Delphi, write out the relevant information in YAML format and then use the LLVM llvm-pdbtil tool to convert the YAML to PDB. Sounds easy and it probably would be except for the fact that the required YAML format is undocumented... The llvm-pdbutil yaml2pdb documentation does a handwave with "The YAML syntax is not described here. Instead, use llvm-pdbutil pdb2yaml and examine the output for an example starting point.". Lazy bastards Anyway, this was just a dump of the information I've been able to gather on the topic of generating PDB from Delphi in case I burn out before completing anything usable.

I have had success with ProDelphi, which has been well maintained. My only complaint is that as it will instrument a maximum of 64,000 routines, on large projects, you must enter a list of folders or files to exclude. That said, I have been very pleased with it over the years. There are 32 and 64 bit versions for Delphi and for Lazarus, and the price is low. http://www.prodelphi.de/

I've had mixed results with that. What we really really need is a way to generate PDB files. If only Emba would add that functionality.

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.