Anders Melander

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?

Yes. Both of them. Very dedicated. If they wanted it fixed I'm sure it would get fixed. It's just a question of resources and priorities. They haven't got them so they've prioritized something else. I have consistently been able to get the IDE hung beyond recovery since Delphi 10. I know exactly what to do, and therefore I also know what not to do. It's pretty much muscle-memory by now. But I haven't reported it because it's no longer a problem for me and I would rather they use their limited resources on something that I can't work around. Improving the compiler, for example.

It's not a progress bar; It's a marquee. Thanks but I think I'll take OP's words over your interpretation of "his needs".

TProgressBar with Style=pbstMarquee. Update it by calling TProgressBar.StepIt.

If you're using TImage then you need to set Transparent=True: The help for TImage.Transparent incorrectly states that the property only applies if TImage.Picture.Graphic is a TBitmap.

If you look at the IDE form designer, you can see that that is also what it does; The client size stays the same between the two Delphi versions. Yes; It's missing the whole <compatibility> section so it basically gets the Windows XP treatment.

I wouldn't mind if they just released it as a technology preview (which is what it is) - on the side. But then what is this release exactly? Sure there are a bunch of bug fixes but have we been paying maintenance all this time to just get a major release (and this is a major release regardless of their silly numbering scheme game) with nothing but fixes for bugs that we already worked around long ago? Will we have to wait another year for something substantial? Two years? Maybe the roadmap can tell us - oh, wait; There's no roadmap, because stupid excuses that nobody ever believed anyway. I asked my manager today if we shouldn't just cancel our Delphi maintenance and gamble on nothing of substance being released the next 3 years (which is the break-even point). The last time we did this (XE3-XE8) we saved a bunch and didn't miss a thing.