Leaderboard

Hello Guys & Girls, Since i'm getting bored to wait from Embarcadero to speed up delphi i thought it would be nice for us ("the community") to help out the things a bit. So i started a new project on the GitHub which it will allow us to build the Fastest RTL is possible for Delphi. The targets are: CPU: PASCAL, SSE3, AVX, ARM Operating Systems: Windows, MacOS, Linux, iOS, Android GPU: OpenCL, Vulkan (Just an idea to use GPU to accelerate RTL) (Single & Parallel routines) What do you think ? I hope anyone will start contribute and make Delphi Fastest Again! Thank you Github: https://github.com/chmichael/UltraCode64 Poll for 32 bit: http://www.easypolls.net/poll.html?p=5d24b2c8e4b02fae1dda847d

https://quality.embarcadero.com/browse/RSP-24834

First step may be to write faster code in pure pascal, with the associated tests. Then add some asm version, and see if it is actually faster. There is already a lot of code in http://mormot.net SynCommons.pas which has faster alternatives than the Delphi version. But two remarks: 1. I wouldn't stick to 64-bit - do why call it UltraCode64 ? 2. FPC compatibility could be very beneficial - as we did for mORMot.

This open source project basically can replace dcef3 or cef4delphi (for embedding the Chromium browser into your program), but the size is much smaller - 6mb zipped. I guess not everyone in the English community knows about it since it's hosted in the Chinese version of github :D https://gitee.com/LangjiApp/Wke4Delphi Basically it's a Delphi wrapper for: https://github.com/weolar/miniblink49

Hello, I’m a certified delphi developer, I have released a library set to optimize and speedup Delphi 64bit applications. It’s useful for any kind of applications; especially servers or isapi webbroker applications, on a modern quadcore cpu, will achieve 3x-4x speed and better, strong reliability. If you wish check www.dellapasqua.com/bettermemory Feel free to contact me for questions or any kind of partnership/collaboration. Thank you and best regards. Roberto Della Pasqua www.dellapasqua.com btw: example test for isapi webbroker: - plain json 400 reqs/sec (not compressed) - zlib deflate 150 reqs/sec (compressed) - this library 700 reqs/sec (compressed: near double reqs/sec with 1/10 bandwidth)

Thanks Remy, not only for this also of your work over all the years now

Post the Quality Portal link, so we can vote and perhaps it'll be fixed...

You are right - now I wonder why that was not used - probably the author of that code also forgot about those 😉

The way broadwayd appears to work is that it runs a single application on a single port for a single user. The connection is persistent because it is a websocket. This means that you need 1 port set up per concurrent user. I came up with some code but it isn't quite right yet. Basically, you have to run broadwayd and the app in the background. I came with this for loop bash script (edit: works now). Make sure you have enough RAM. #!/bin/bash for i in {1..99} do nohup broadwayd :$i & export GDK_BACKEND=broadway export BROADWAY_DISPLAY=:$i ./FireMonkeyPaintDemo & done Once you get your application running on 100 ports in the background (which will support 100 simultaneous connections/users) then you need a TCP load balancer to turn the 100 points into 1 port. One such tool is HAProxy: https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/ A simpler tool (with maybe less performance) is called balance (sudo apt install balance ). https://www.systutorials.com/docs/linux/man/1-balance/ Here is a sample command which would load balance 4 broadwayd ports as port 81: balance 81 localhost:8080 localhost:8081 localhost:8082 localhost:8083 After running this and the above you would be able to connect to localhost:81 and it will load balance you across the 4 backend ports. You can probably also do this with TIdMappedPortTCP.

The last 8-9 years I've had the luxury of pretty much staying current with the Delphi versions. We usually skip the first releases like 10.2 or 10,3 and migrate when the 10.2.1 or 10.3.1 arrive. This has become a little harder as the so-called minor upgrades now also have a lot of changes and even new stuff., but we tend to wait for the first "fix pack". That allows the new versions mature for a while so that TMS, EurekaLog, FastReports, and others can work out any new quirks, and the bleeding edge crowd can draw first blood, but as I said, we do aspire to move on to the latest version as soon as it seems tried and tested. Back in the day, skipping several versions often raised headaches when finally deciding to migrate as you had to deal with multiple incompatibilities or breaking changes, so I much prefer the current approach. To be honest, in some cases I actually wish that EMBT would be bolder and more often introduce breaking changes to tidy up old sins. On the topic of unit dependency cycles, I tend to view them as a design weakness. It is a quick workaround for properly designing with DI and other tools that eliminate unit inter-dependencies. Yet, working with code that has evolved over a long time, they can be hard to eliminate as they are so deeply ingrained. We have one particular unit that causes a compiler internal error whenever we change something in its interface section and do a compile in the IDE. At that point only a Build All resolves the problem.