Brandon Staggs

This is the only viable solution.

Seriously, show the whole unit.

I'm glad you did post this here! Thank you! Alas, it does not resolve debugging speed issues on MacOS 15.4+.

I don't understand what you mean by that. Bottom line: inc files still exist and work just like they always have: If you include a file its contents are placed in-line where you include it when the unit is compiled. Where that "right place" to include it is, depends entirely on what you are roping into your unit. "Useful records" definitely do not make sense as inc files. Source code included in Delphi uses inc files extensively and I wish it didn't. It makes understanding the units and navigating source take longer. There are good reasons to use inc files, such as defining compiler directives that you need to be consistent across multiple units, but if your "stuff" can just be made into units, then it should not be placed in inc files. IMO. :-)

You may as well just stuff all your classes into a single unit so you can achieve this. You don't need the language to undergo a fundamental redesign. As projects grow the issues with circular references can become annoying. I know this well. But the solution is to do better class design, not to embrace the excessive coupling of the classes.

Good information in this thread. @David HeffernanI was actually interested in your reasons for not using SameValue and what you use as an alternative.

Why is it lethal to puppies?

No serious developers are interested in binary-only Delphi components.

Used Apple's support for dual-boot to install Sonoma. Debugging works perfectly fine there.

This did not make a difference.

Well, I did say other Delphi code, but as it turns out, I am able to debug some applications nice and fast, but the "big ones" are ultra-slow. The only difference I can think of that would matter is that the main large application I am having trouble with creates a lot of threads. I know on Windows this can slow debugging down depending on what DLLs are being attached to the threads. So I created a simple app that spins off 100 threads just to see if I could debug it reasonably. That worked fine. So clearly, something we are doing in our application is, somehow, affecting debugging speed. I don't know what that could be. One test I did was to directly run the LLDB debugger from within the PAServer 23 application bundle. It was able to run the application at what seemed to be full speed. I am tempted to learn how to properly use LLDB just because it seems to provide a very snappy debugging experience, even if it is limited since it is not connected with the IDE at all... In desperation I updated to MacOS 15.5 beta 2 just to see if anything would change. Nothing did. I am pretty much stumped at what could cause MacOS ARM64 debugging session to slow to a crawl in Delphi that wouldn't also cause things to go slow on an Intel-based Mac. If I deploy the exact same project to my old Intel MacBook, the main difference being that the build generates x64 code of course, it debugs acceptably. If I deploy it to my M2 (ARM64 build), it debugs at a snail's pace. Ugh.

Other Delphi code. I updated the Mac from 15.3 to 15.4. Sequoia 15.3 was working fine, but I am not 100% sure that this issue coincided with the update. PAServer is deploying over 150 megs of binaries (the app and a bunch of dylibs) in just a few seconds; I use a 2.5 gig wired network connection for this and disable wifi so that PAServer doesn't try to use a slow connection. If there are network issues it's not due to speed but could still be other problems. I will look into that. I am also wondering if upgrading to Delphi 12.3 with the updated PAServer will matter. That's kind of a last resort at this point and seems very unlikely to make a difference.

I'm developing on real hardware. As far as I know there is no legitimate way to run MacOS in a VM, but my information may be outdated. I switched to using a much older Intel MacBook Pro with an older OS, and debugging speed is acceptable on that. I do suspect the OS update. Before this began, debugging and stepping through ARM64 code on the Mac was actually quicker than stepping through Win64 code on the same PC as the Delphi IDE, which I always found ironic. I tried debugging other code on the M2 and all of it was extremely slow.

I am hoping someone else has experienced this and can share a solution. Last week my debugging MacOS applications through PAServer became extremely slow. Code executes but (apparently) the communication between the debugging process on the Mac and on the Windows PC is so slow as to be unusable. If I detach from the process the application will suddenly start running at normal speeds. No breakpoints are needed for this problem to happen, just the act of running it with the debugger attached slows everything down to an unusable speed. It is possible, but I do not know if this timing is correct, that this happened after updating the Mac to Sequoia 15.4. The Mac is an M2 Pro model with a 2.5 gig wired ethernet connection (wifi disabled). Deploying to the Mac is super fast from Delphi. It's not a network speed issue. I have already tried updating XCode and updating the SDK profile in Delphi. Details: Apple M2 Pro, Sequoia 15.4 Wired ethernet (2.5 gig), deployment speed is very very fast even for large transfers. Delphi 12.2. Target: MacOSX ARM 64 bit, SDK 15.4. Does anyone who debugs MacOS FMX applications have any suggestions on what might be suddenly slowing down the debug process? I can confirm that code is running and I can step through it, it's just SUPER slow to do so, the main form takes several minutes to appear (but eventually does), after which it remains ultra-slow.

No, I don't see the point -- there are already so many people who actually do hardware comparisons for a living writing about it. Aside from commenting here in the context of a Delphi developer, I don't have time to write my experience in detail. I will just add this: I bought a Snapdragon Windows PC when I saw that users of my software were installing it on Snapdragon Windows PCs, but that the 32-bit version of my software was appearing instead of the 64-bit. I quickly realized this was due to how the Inno Setup script was written, which assumed that if x64 was not available that the system needed the 32-bit x86 binaries installed. Inno added support for some additional scripting functions to better handle this and I wanted to test my software on Snapdragon so I bought one and fixed the install script. That works perfectly. And now any time I need to grab a portable PC I take the Snapdragon one because its the lightest Windows PC I have and the one with the best battery life. I've had no issues doing what I need to do on it. This is not some cheesy WinRT netbook from 12 years ago that can only open a web browser and play Candy Crush and run Office apps. This is the Windows answer to an Apple MacBook (which I have two of also).