Leaderboard

We present an implementation of multicast events that is as lightweight as regular Delphi events in common scenario's. Also - for those interested - we show a couple of not-so-common Delphi language features that are used in the implementation. https://blog.grijjy.com/2023/04/27/lightweight-multicast-events/

Why not? My experience is that the OS is largely unimportant because it's the hardware that matters. Well no, but that's not even remotely what I'm talking about. My competitors aren't coding for 90s Crays. They are coding for today's hardware, as am I. For of all, we haven't been getting annual doubling of performance for quite a while now. But again I'm not competing against last year's computers. The developers writing code that competes against mine are also able to use that same hardware as me. Just because performance isn't important to you doesn't mean that it isn't important to others. Your experience of the world isn't the same as others.

For older versions there's always this one: Multicast Delegates - An amazingly simple and elegant solution and, as far as I can tell, even more versatile.

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).

Performance can be an issue, but most of the time it's not really the performance of the generated code but the wrong algorithm selected by the programmer or a faulty implementation of that algorithm. Only after the best algorithm has been selected (and properly implemented) the optimization of the compiler becomes an issue. I have had several performance bottlenecks that were solved by simply turning on optimization (which I usually leave turned off due to it not making any difference and sometimes creating issues). But once you get to manipulating large amounts of data that reside in RAM, the poor quality of the compiler begins to show. But in my experience these situations are rare.

According to Matthias Eissing (Embarcadero Germany) it's based on Delphi 11.3 pro including Patch 1. The usual restrictions apply: No command line compiler, license valid for 1 year, restricted to non commercial or "low commercial" use. Announcement in the German Delphi Praxis: https://www.delphipraxis.net/212933-delphi-community-edition-11-verfuegbar.html#post1521576 Announcement on the Embarcadero website: https://www.embarcadero.com/products/delphi/starter

Welcome to forum! I am no clairvoyant and I assume nobody here is. So without showing anything how you do, what you think we can say? Watch line 123 there at call xyz you did something wrong?! Best practice would be a small demo zipped that shows us what you do and how you try to achieve that.

One more of those endless topics 🙂 Talking about poor performance of Delphi, remember there are Electron applications 🙂

No. It shows that there's some problem. It doesn't show that the bug is still there. Btw, I guess it's this one: RSP-27825 (status: Closed, resolution: Fixed, fixed version: 10.4.1). Or they could step on yours. 🙂

In my experience, if performance is really critical on a project, then first of all, Windows is NOT the platform you want to be working on. Second, you certainly don't want to be stuck using a programming language / system built around building apps that are based around forms used to interact wiht a DBMS somewhere off-premeses. But that's just me. I would never even take such a role, and I've been offered several. They make me want to reply, "What part of 'square tires will never be as smooth at rolling down the road as round tires' don't you guys understand?" You cannot "optimzie" rolling resistance out of square tires. They just think we're all a bunch of "dumb programmers" and that "poor attitudes" are to blame. Phones today are many times faster than Cray computers were in the 90's. Don't expect me to agree that getting a few more percent of performance from compiler optimization is important when CPUs a year hence will offer a a 2x-5x improvement right out of the box with zero optimization. I do realize there are environments that rely on old hardware and software for safety and durability reasons, but if compiler optimization is really a make-or-break proposition, you're way too close to the edge of a very dangerous precipice, IMHO.

Delphi 11 Community Edition based on 11.3.1 Pro

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

I think that 98% is a high amount, however, without technical and reliable proof, I will accept if you give me a 20% discount for paying in cash! But of course, Piette, you may be correct in saying that most don't really need that much computing power to perform a "CRUD": select, insert, update and delete! For the others, everything will still be little, in view of their personal needs, more than professional and market needs. Bear in mind that they will never be able to reach "that" that is filed within them, and is already part of it! "It's the dog chasing its tail!" - but it's fair, maybe one day they'll feel the bite

Probably 98% of Delphi users don't care about math speed for what they have to do. Only those doing math intensive applications do care. So you care and Patrick doesn't, me neither

http://www.isdelphidead.com

Hi Bucket name is different from folder name, you have to call it as Service.UploadObject(bucketName, folderName + '/' + objectName, ...

This post indicates a "workaround". Not sure why this is necessary. Is your app an FMXLinux app? https://synaptica.info/en/2020/11/26/delphi-fmxlinux-launcher-icon/