Leaderboard

New version with @Stefan Glienke's improvements uploaded. https://bitbucket.org/anders_melander/map2pdb/downloads/ Notable changes: VTune now attributes samples to the correct source lines within a block. Removing RTTI from the exe has reduced the size by 15%. The pdb is now being built in a temporary memory stream which is significantly faster due to reduced I/O.

I too have that problem. So far I haven't been able to profile our main project because the symbol resolution step takes longer (hours) than I'm willing to wait. It's probably caused by a bug in map2pdb (e.g. some hash table is incorrect) but for now my plan is to add a white/black list option to include and exclude units from the pdb. So for example if I specify the switch -exclude:dx* then any unit that starts with "dx" (i.e. DevExpress) will be excluded from the pdb. It's hard to spot but there's one at the bottom of the download page: https://software.intel.com/content/www/us/en/develop/articles/oneapi-standalone-components.html#vtune I'm on Windows 7 so I had to find an older version of VTune. VTune 2019 was the last one to support Windows 7. Unfortunately it's a trial and it expires in a week...

Of course absolutely no. Evil Russian hackers will drain all of your bitcoins in seconds just between faking US votes and drinking vodka with their bears

It took me a bit longer than expected to get here but I believe I've finally reached the goal. The following shows VTune profiling a Delphi application, with symbol, line number and source code resolution: Download Get the source here: https://bitbucket.org/anders_melander/map2pdb/ And a precompiled exe here: https://bitbucket.org/anders_melander/map2pdb/downloads/ The source has only been tested with Delphi 10.3 - uses inline vars so it will not compile with older versions. Usage map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Parses the map file produced by Delphi and writes a PDB file. Usage: map2pdb [options] <map-filename> Options: -v Verbose output -pdb[:<output-filename>] Writes a PDB (default) -yaml[:<output-filename>] Writes an YAML file that can be used with llvm-pdbutil -bind[:<exe-filename>] Patches a Delphi compiled exe file to include a reference to the pdb file -test Works on test data. Ignores the input file Example: Configure your project linker options to output a Detailed map file. Compile the project. Execute map2pdb <map-filename> -bind Profile the application with VTune (or whatever) Known issues The -bind switch must occur after the filename contrary to the usage instructions. PDB files larger than 16Mb are not valid. This is currently by design. 64-bit PE files are not yet supported by the -bind option. As should be evident I decided not to go the DWARF route after all. After using a few days to read the DWARF specification and examine the FPC source I decided that it would be easier to leverage the PDB knowledge I had already acquired. Not that this has been easy. Even though I've been able to use the LLVM PDB implementation and Microsoft's PDB source as a reference LLVM's implementation is incomplete and buggy and the LLVM source is "modern C++" which means that it's close to unreadable in places. Microsoft's source, while written in clean C and guaranteed to be correct, doesn't compile and is poorly commented. Luckily it was nothing a few all-nighters with a disassembler and a hex editor couldn't solve. Enjoy!

@Mark Williams Might be OT because you refering FireDac. So just for the record: I added that feature to Zeos V8. See: Add ArrayDML returning feature for Postgres Chears, Michael

I found the problem with HEAD and some redirections, it failed to start the redirected request until close was called, a bug that seems to have been there for many years. Looked at my own link checker and I use GET not HEAD which is why I've never seen it. Your 404 error page returns content even for 200 and HEAD. It will be in SVN tonight. Angus

That would be great. Here are some relevant lines of the log file, I doubt they are of any use, though: 2021.04.08 14:23:10.909 #DEBUG #PeFile::Open #PeFile.cpp(111) #Executable (PE) C:\Windows\SysWOW64\ntdll.dll opened 2021.04.08 14:23:10.137 #DEBUG #PeFile::InitializeSymbolEngine #PeFile.cpp(699) #Executable (PE) C:\Windows\SysWOW64\ntdll.dll started Symbol Engine initialization 2021.04.08 14:23:10.752 #DEBUG #PeFile::InitializeSymbolEngine #PeFile.cpp(751) #Executable (PE) C:\Windows\SysWOW64\ntdll.dll initialized Symbol Engine: PDB 2021.04.08 14:23:10.662 #DEBUG #PeFile::Open #PeFile.cpp(111) #Executable (PE) D:\DelphiSource\DelphiRio\mystuffR\uProfTest\Win32\Debug\uProfTest.exe opened 2021.04.08 14:23:10.945 #DEBUG #PeFile::InitializeSymbolEngine #PeFile.cpp(699) #Executable (PE) D:\DelphiSource\DelphiRio\mystuffR\uProfTest\Win32\Debug\uProfTest.exe started Symbol Engine initialization 2021.04.08 14:23:10.113 #DEBUG #PeFile::InitializeSymbolEngine #PeFile.cpp(758) #Executable (PE) D:\DelphiSource\DelphiRio\mystuffR\uProfTest\Win32\Debug\uProfTest.exe failed to initialize Symbol Engine: PDB 2021.04.08 14:23:10.740 #DEBUG #PeFile::InitializeSymbolEngine #PeFile.cpp(778) #Executable (PE) D:\DelphiSource\DelphiRio\mystuffR\uProfTest\Win32\Debug\uProfTest.exe initialized Symbol Engine: COFF

I don't know about C++Builder and map files but in any case there would be too many differences, caused by all the other stuff that VS outputs, to make that feasible. What I've done previously, when I had to figure out why something didn't work, was to use a hex editor to compare the pdb of VTune's matrix example with the output from "map2pdb -test". They are both sufficiently small. At this time I can pretty much parse pdb just by looking at the hex 🙂 I think the easiest way forward would be to just examine the key suspects (address table, hash tables) of matrix.pdb in a hex editor and verify that they're ordered and structured like we expect them to be. I'm using @mael's HxD editor so if would help if that supported structures. tap.tap... 🙂 Another way would be to write a drop-in replacement for the msdia140.dll in-process COM server, which is what VTune uses to access the PDB data (I considered doing that at one point since it would completely eliminate the need to write pdb). That would tell us exactly what API methods VTune is using and how.

filed by Ian Barker https://sourceforge.net/p/gexperts/bugs/244/

Use the web installer, you can then choose which parts to install.

Hi! I don't know that any specific repo can be trusted when it comes to BTC etc. without intense static analysis be it Russian or not. Also keep in mind that GitHub itself has been subject to a mining attack whereby a pretend-NodeJS instance was available and executed which would perform crypto mining leveraging GitHub servers, so... kinda shady the whole thing whoever does it. But this library is developed in C# so static analysis is an option and I think there are several products that can do it. Static Analysis is your first line of defense, especially if you can establish "shady patterns" to look for. I am muchly more worried about situations where, say, the repo is on Russian/Chinese servers and with Internet-related laws that are questionable at least, if not downright awful. Static analysis is your friend, mate, use it!

Maybe heroes from the Marvel Universe are capable to read fast enough and click I just get headache when for some reason get to the site.

Growing impatient while building your FireMonkey app for macOS, iOS or Android? This post shows a way to (significantly) decrease the amount of time it takes for your app to build on these platforms. https://blog.grijjy.com/2021/04/05/build-speed/

While LLVM certainly is part of the situation it suffers from the same sickness that makes most C++ code compile terribly slow: templates - err, I should say generics. (precompiled headers anyone?) Especially FMX uses them like everywhere if it makes sense or not. Everything is a TList<something> and there are many generic types within FMX itself. So the compiler has to build all these generics for each and every unit. Yes, if you have 1000 units using TList<TComponent> then that code is being emitted into 1000 dcu files and in case of LLVM also .o files including all that RTTI and possibly gigantic debug information for that TList<T>. The linker later eliminates any duplicates so the final binary does contains the code and RTTI only once. I know this from refactoring spring4d where I redesigned the generic collections to produce as little code as possible and turned off RTTI for all the implementing classes which improvided compile time on some projects by a factor of 4. Unfortunately even with the new intrinsics introduced in XE7 that were for reducing binary size because it enables compiletime optimizations for the code (GetTypeKind and alike) there is some significant bloat happening as I reported some time ago. When you fancy and look into a map file for a typical FMX application you can see that a huge chunk alone is from system.generics.collections and most of that code is dead code because it's only in the binary because RTTI is turned on for those classes. Even if they are used as private fields in some classes and all that is ever called on them is Add and Delete the entire code is emitted by the compiler. So a significant part of the compiletime is being used producing garbage (emitting code into dcu/o files) that the linker later has to find and eliminate. Edit: To emphasize: generics alone are not bad - its the overuse of them and making them fatter than they need to be and having RTTI being turned on for them. Often in places where a class reference would have been enough instead of some fancy<T: TSomethingclass>

I just had my first big win with VTune 😃 I was looking into improving the performance of loading projects in FinalBuilder 9 (in dev) - we have some customers with huge projects that were taking a while to load. Profiling with VTune showed that most of the time was spent in the project lexer/parser - the lexer created class based tokens (and some other associated classes) and a lot of time was spent in the lexer and the memory manager. So 3 hours later, the code has been converted to use records rather than classes - the unit tests all pass (I only had to comment out all the Assert.IsNotNull(token); calls) and the application runs normally (still need to code review to make sure I didn't break things). The result is around a 30% improvement with that change alone! That's just me counting out loud as the project loads 😉 - I'll do more formal timing/testing tomorrow. I also just compared to FinalBuilder 8 and the total improvement is more like 60% - I'll put that down to some manual code review looking for possible hotspots over the last week, and also to switching from the rtl generic collections to using spring4d everywhere! Time for some sleep, but looking forward to more VTuning tomorrow. Thanks @Anders Melander again for this amazing bit of work!

Put the labels in an array, and then access them by index, or Use a single label, and include linebreaks in the caption, or Create the labels dynamically, or Probably some other solutions that I have not thought of.

Well that's what happens when you strip the team down to the bare bones and then hire short term contractors, maintaining things becomes a problem when your teams domain knowledge is low. FWIW, 5 minutes in and I already fixed a perf issue in the area that I have been trying to optimise for the last week (replaced a list with a hashset) - a small win but I'll take any win I can get right now😃 Pity embarcadero don't ship map files for their bpl's - hmmm will log a qc for that - because as I dig deeper into my perf issues I end up in the weeds in rtl etc with func@xxx a lot.