Anders Melander

Yes it does - but map2pdb just produces the pdb files required by the profilers. Profilers that works with pdb files includes Intel VTune and AMD μProf. I believe μProf works with both Intel and AMD processors while VTune only works with Intel processors but use the one that matches your processor to get the most precise results. I use VTune myself. Ask if you need instructions on how to get started. The process is very easy once you know how to do it but it can be challenging to get to that point 🙂

Yet you did. If you couldn't remember where you got the code from then you simply shouldn't have posted it without proper attribution. As it is now the code is nearly identical so it's not just "inspired" or "influenced". That's not a problem in itself, it's open source after all, but you have to at least keep the original license which is "MPL 1.1 or LGPL 2.1 with linking exception". I've created an issue at your repo to get that fixed.

In other news, Lazarus, the North Korean hacker group has released a statement saying it would be better for them if people would please click on the link in that email ebay has just just sent them asking to update their account details. "There's too much mistrust in the world today" said Park Jin Hyok, a spokeperson for Lazarus. "Just click it, godammit".

For benchmarking, sure. But otherwise I would think it would be better to let Windows manage that. That code sure does look a lot like this one... https://github.com/graphics32/graphics32/blob/4fbc8d2a3083e42a00ca776eaa52af7cab2de34a/Source/GR32_System.pas#L399

Do you really need reentrant locks? If not then just use the standard version. There's no need to complicate thing further. Also MREW only makes sense if you have more readers than writers. For single writer & single reader there's no reason for it. As I read it you are considering using a pool of reader in which case MREW might very well make sense (or "just" use a lock free queue). Btw, if you don't need to process the work packets "in order" then things become a little easier since a lock-free stack is often simpler to implement than a queue. A PWideChar doesn't necessarily mean that the source string is a Widestring. It would very well just be a pointer to regular unicode string. It's just not common to explicitly use PWideChar anymore since it is the same as PChar on unicode Delphi. Regardless, the message was more that you should avoid WideString unless you have a reason to use it. You can't really do anything about what your external lib uses internally. Good luck. You have many hours of debugging ahead of you 🙂

I didn't investigate but I got a lot of leaks reported when existing the application when running in the debugger. Okay. It's expensive to start a thread but if you are launching the threads at application startup then it doesn't matter. If you create them on-demand then I would use TTask instead. The first task will take the worst of the pool initialization hit. https://en.delphipraxis.net/search/?q=profiling If you use a lock-free structure then you don't need locking. Hence the "free" in the name 🙂 And FTR, the term deadlock means a cycle where two threads each have some resource locked and each is waiting for the other to release their resource. I think what you meant was race condition; Two threads modifying the same resource at the same time. PWideChar is supposedly a pointer to a WideString? In that case, please don't. WideString is only for use in COM and it's horribly slow. No, what I meant was that instead of using dynamic strings (which are relatively slow because they must be allocated, sized, resized, freed, etc.) use a static array of chars: Buffer: array[BufferSize] of char. You will waste some bytes but it's fast.

Did you read the text you just quoted?

Yes. For one you are running all the tests concurrently which means that you will be penalizing the tests that start later because they will be competing for CPU against the test that are already executing. Execute each test and wait for it to finish before you start the next test. You also seem to have massive memory leaks which probably means that some of the test have an unfair advantage because they don't consume time releasing their resources. If you are using thread pools (I'm not sure that your are (if not, you should be)) then you should ensure that the thread pool has been spun up before you start the test. Otherwise you will penalize the first threads with the startup overhead. Instead of just looking at the time from start to end and then guessing about why it is fast/slow/whatever, profile your code so you can see exactly where the bottlenecks are. Do this for each individual algorithm in turn. Apart from that, for something as simple as this, you don't need locking and you definitely don't need to use the Windows message queue as a work queue. Use a simple lock-free fifo queue instead. You could even use a fixed size lock-free ring buffer (just an array of records with two integer values as in/out indices). The fixed size buffer and the records would eliminate the allocation overhead of the queue itself. You should probably also try to eliminate the use of string and replace it with fixed size buffer if possible.

I really think it's more a question of lack of expertise, limited resources, and priorities. I think they would if they could but since they can't communicate that to the customer they instead come up with excuses that comes across as if they don't care.

https://en.delphipraxis.net/search/?q="Delphi 12.3"&sortby=newest&search_and_or=or&page=1

Thanks for explaining that to me. Now I understand everything exactly like I did before. I don't have any code where anything in system.generics.collections or system.generics.defaults is anywhere near the bottleneck Better?

Nice! Unfortunately I don't have any code where generics is anywhere near the bottleneck or I would have had a go with it.

It looks to have the same interface but jeez it's a lot of code to maintain.

Use an interposer for TDataModule. The datamodule base class (no DFM): unit Foo.Bar; interface uses Classes; type TBaseDataModule = class(TDataModule) private FFoobar: integer; public property Foobar: integer read FFoobar write FFoobar; end; implementation end. Your datamodule: unit Whatever; uses Classes, etc. etc., ... Foo.Bar; type // The interposer // You could have declared it in the Foo.Bar unit but I prefer to declare it explicitly // everywhere it's used to make it clear what is going on. TDataModule = TBaseDataModule; // Your regular TDataModule stuff type TMainDataModule = class(TDataModule) ... end; etc.

Me too - and I would most often also start with the class vars and types. Of course it depends on the size and structure of the class; For a large class I would probably try to keep associated stuff close together as an overriding principle.

type TClass = class(TObject) private FSomeField: integer; private const SomeConstant = 5; private type SomeType = integer; private class var SomeClassVar: integer; end; etc. etc.

Why not "context: pointer" instead of "context: UIntPtr"?

What can I say? Whoosh?

The pdf appears to be 🐸-encrypted 😉

I haven't used Access in... 25 years I think, so I can't help with specifics. My guess is that you need to set up a ODBC DSN using the ODBC Data Source Admin. Once that is done I think you can configure FireDAC to connect to the ODBC DSN.

It would probably be relevant if you explained what you mean by "no success". What errors are you getting, if any? What does your FireDAC connectionstring look like, etc.?

That's why they pay us the big bucks 🙂 Here's some links that might be relevant: https://learn.microsoft.com/en-us/office/troubleshoot/access/cannot-use-odbc-or-oledb https://how-to.aimms.com/Articles/129/129-MSACCESS-32bit-64bit.html

By "3rd party" I mean 3rd party libraries. They seem to have all abandoned WinUI3. Likely because there isn't any demand from their customers. Come on. That document is 6 years old but even if it was written yesterday it wouldn't make WinUI3 any more relevant. Try harder. How does the existence of XAML Islands "prove" a demand? Do you understand that "prove" implies that "proof" exists? My mention of Clipper was in reference to your hyperbolic claim that "Embarcadero has been a leader in wrapping and integrating native APIs". If anything they have been known for lacking behind their peers, such as C++, C# and Java in this regard, so how can they be a leader? Delphi is very good at wrapping native APIs but the potential future existence of these wrappings doesn't make it a leader. They have to actually exist. Anyway, I've already spent more time on this topic than I care. Peace Out.

I think your arguments are all over the place but ignoring that, IMO they will not, and should not, waste resources on WinUI3. It's DOA and has no 3rd party support. Move on. LOL. Compared to what? Clipper?