Delphi 13 Florence: 64-bit IDE debugging experience

-

Anyone who has ever debugged a 64-bit application in Delphi, especially one that involves multiple threads, has probably experienced disconnected session issues, or the IDE not showing watch values, or simply getting non-responsive in the middle of a debugging session.


The new 64-bit IDE and its LLDB-based debugger provide a solution to such problems. You may no longer have to sprinkle your code with logging code that is otherwise not needed; nor will you have to waste hours trying to catch some error, only for Delphi to die on you when you are two lines of code away from discovering the problem.

However, it is not all that peachy. Namely, LLDB has its own quirks.

First of all, it is dog slow. It is slow when evaluating breakpoints, it is slow when handling exceptions (even ignored ones), it is slow when it stops at a breakpoint and shows local variable values. The more powerful computer you have, the better the experience will be.

While there is still plenty of room for improvement in this area, and I expect that there will be continuous speed improvements in further releases, the LLDB will never be as fast as the old, handcrafted Delphi debugger, just like the LLVM-based compiler's speed will never match the handcrafted Delphi compiler. The LLVM and LLDB toolchains are just slower, and that is a fact of life we have to deal with.

The fact is LLVM/LLDB were originally written for C and C++ languages and ever since the Turbo Pascal era, Borland/CodeGear/Embarcadero Pascal/Delphi compilers were known to run circles around the C and C++ compilers, and we have all been spoiled by their speed.

Another problem is that the LLDB debugger lacks some features of the old handcrafted Delphi debugger, which was made specifically for Delphi and is fine-tuned for its language features. Again, there is still room for improvement in this area, too, but adjusting a general-purpose toolchain which was built with C and C++ in mind will take time, and it is possible that there will always be some discrepancy between what the old compiler/debugger could do compared to the LLVM/LLDB-based equivalents.

In that light, as long as you still have the old debugger and 32-bit IDE, you may still want to do your base development and debugging in the old IDE, unless you have other reasons to use the 64-bit one by default, like a project that is too large for the 32-bit memory space.

But when the 32-bit IDE starts acting up during debugging, instead of cursing and pulling your hair, you can turn to the 64-bit IDE. Maybe you will progress at a tad slower pace, but you will be able to complete the debugging session without any interruptions and find the information you were after.


Comments

Post a Comment

Popular posts from this blog

Universal storage for Delphi procedural types

-
Delphi's procedural types fall into three categories: standalone procedures and functions, methods, and anonymous methods. The variables that can store those types are all different, both in their memory size and their nature. Further differences between various procedural types come from the number of parameters they have and their types, as well as whether they return some result—whether they are functions. Those differences have an impact on how they are invoked, but not on their storage—the variables and their memory layout. Two procedural types will be compatible with each other, if they are of the same category, have the same calling convention, have the same number of parameters (including the return value or lack of it). and those parameters and return value are of the same types and declared in the same order. The declared parameter names can be different, and don't affect this compatibility. Declaring any of those procedural types has some common parts: a type iden...
Read more

Delphi 12.3 Update

-
Image
The Delphi 12.3 update has just been released. The most exciting part of this release is the long-awaited 64-bit IDE. Now, this is only an Initial Release of the IDE, and it is not yet a full replacement for the 32-bit IDE and its functionality. The main advantage of the 64-bit IDE is that the available memory is no longer constrained by the 32-bit address space, and the upper limit is now the available system memory. The more you have, the more you can use. This is a great news for all developers with large projects, where the 32-bit IDE would easily hit the memory wall. To start with, the 64-bit IDE only supports the 64-bit Windows platform. The primary purpose of such a release with only partial functionality is to allow all component developers to update their design-time packages, and prepare them to support the 64-bit IDE. And to do that, you only need the 64-bit Windows platform anyway. For all other platforms, there is no immediate advantage of using a 64-bit IDE. As we all...
Read more

Celebrating 30 Years of Delphi With a New Book: Delphi Quality-Driven Development

-
Image
This year, on February 14th, Delphi celebrates its 30th birthday. Over the past three decades, Delphi has proven to be a robust and versatile development environment, empowering developers to build high-performance applications with ease across multiple platforms: Windows, Linux, Android, iOS, and macOS.  As we commemorate this milestone, I am also introducing a new book to help guide you into Delphi's fourth decade: Delphi Quality-Driven Development. Useful to lone developers and vast teams alike, this book aims to demonstrate a variety of essential practices and techniques for making high-quality, testable code. There is a 25% sale going on until the end of February for the Delphi Quality-Driven Development ebook, and there you can also get an additional discount on other books if you add them to your order. To all my fellow Delphi developers: May your code compile quickly, your memory be manageable, and your code testable.   Delphi Quality-Driven Development Book A practica...
Read more