Stefan Glienke

{$IFOPT R+}{$DEFINE RANGECHECKS_ON}{$R-}{$ENDIF} TempInt := TempInt * 11; {$IFDEF RANGECHECKS_ON}{$UNDEF RANGECHECKS_ON}{$R+}{$ENDIF}

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Procedural_Types_(Delphi)#Method_Pointers

Event types and TMethod while binary compatible (both consist of the data and code pointer) they are not assignment compatible. This routine will work for all event handlers that have the TNotifyEvent signature but not for others (such as mouse or key-related ones that have additional parameters). For those, you need to write overloads. procedure SetDefaultEventHandlerIfEventExists2(const AControl: TControl; const AEvent: string; const AHandler: TNotifyEvent); begin if IsPublishedProp(AControl, AEvent) then SetMethodProp(AControl, AEvent, TMethod(AHandler)); end;

I read "branchless" and I cry - see RSP-21955

Turn the strings into an enum or an index and put the functions into a const array over that enum/index.

Could the documentation be of any help?

No, it's not - it's the call from this line: https://github.com/microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1627 It however might look different today given that source on GitHub is from seven years ago but it might still give a clue. The weirdest way I got a "thank you" ever ngl

FWIW: https://github.com/microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1385

@Anders Melander Might be worth looking into https://github.com/llvm/llvm-project/blob/main/llvm/lib/DebugInfo/PDB/Native/PDBFileBuilder.cpp

This could be some relevant info: https://randomascii.wordpress.com/2023/03/08/when-debug-symbols-get-large/

Yes - because apparently according to the warning, there is a problem with "match the module with the symbol file". It could be very well a VTune bug though - after all the 2023.1.0 we currently get is a "pre-release".

I can't - as I confirmed the breaking change is from 2023.0.0 to 2023.1.0 and that explicit mention of large pdb file support was the most obvious clue. I don't know anything about the pdb format.

I just upgraded from 2023.0.0 where it worked to 2023.1.0 where it does not. What I noticed in the change log of VTune 2023.1.0 is this: Debug Support Support for Large PDB Files Starting with the 2023.1 version, on Windows* systems, you can resolve debug information from PDB files larger than 4GB. Could it be that the address bitness written by map2pdb is not correct now? In the collection log of VTune I can see this warning: Cannot locate debugging information for file `somepath\Tests.exe'. Cannot match the module with the symbol file `somepath\Tests.pdb'. Make sure to specify the correct path to the symbol file in the Binary/Symbol Search list of directories.

Personally, I would find it way more readable if you would not ifdef DELPHIAVX for every single line but simply make it two blocks, one using the avx instructions and one using db.

So you are saying that your app is already using more than 2GB (or more, large address aware and all that) and might not have enough space for allocating a simple string to store a file path in... But at the same time you are talking about using a form and showing information there... and where do you think the VCL (I am assuming you are using the VCL and not creating your form by directly accessing the winapi) takes its memory from? And worrying about the performance impact of try while scanning directories on the file system? Sorry, but this all makes absolutely no sense.

Wait what? Well first of a string is basically a pointer so you could store that inside of the pointer - nobody is talking about storing the string content into a pointer - you could only ever store 2 or 4 Unicode characters in there. So yes, of course, it's about storing the string index into the pointer.

Cannot be - if it's decremented by more than 1 then because the method was called more than once, simple as that. If the method is being called from multiple threads you need to use AtomicDecrement though. If you don't know from where the method is being called unexpectedly, use a data breakpoint on MyValue and the debugger will stop as soon as its being modified

If it's just a string variable you don't need to heap alloc anything - either use a const if you already know the exact content or use a preallocated buffer.

You could (ab)use the objects part of the first stringlist entries as index of the entry in the second stringlist 😏 To be more serious - while the dictionary is a fair approach it leads to duplicated data which can make updating data more complex. To find a good solution it might be worth it to explain a bit more about the data and the use case itself. You also mentioned a TStringGrid for UI which I personally find a terrible component.

As Dalija already mentioned some things that you need to do in a parallel environment add some overhead. This means that when the actual workload you are doing (such as incrementing a number) is so small that added overhead dominates the overall time. We all can agree that incrementing a number is not a suitable task to be executed in parallel. However, if you were to do some real-world tasks in parallel, there are still some things to consider - such as what has been discussed some while ago on StackOverflow, namely partitioning of data to process it in parallel properly.

Don't bother and simply use BigInteger from https://github.com/rvelthuis/DelphiBigNumbers (or rather https://github.com/TurboPack/RudysBigNumbers which seems to be the maintained fork) - it most likely has all operations that you need

When comparing the costs of GitKraken (4.95$/month/user) vs a one-time purchase of $49.99 I would say that either GitKraken is a rip-off or has some impressive feature set and offers way more than what a graphical git client has to offer.

Rhetoric 200 - What's Whataboutism?

If it weren't for other statements already this one really disqualified you from even participating in any performance-related discussion. I just recently updated from an Ivy Bridge CPU to a Raptor Lake at home and the single-thread performance of some Delphi benchmarks approximately doubled. If you don't believe my sample then simply take a look at https://www.cpubenchmark.net/year-on-year.html You see that in about 10 years the single thread performance approximately doubled (and even less on server hardware). And when we think about how the real gains in performance are achieved these days (parallel computing) Delphi is even in a worse situation given the poor support for anything parallel computing (yes, it can be achieved but you need to handcraft a lot of code and much existing code does not scale well at all).

"An E-Smart is a pretty fast and comfortable car!" - grandma who only ever drives to the local grocery store.