Forum

Notifications
Clear all

HTTP middleware benchmarks

4 Posts
2 Users
2 Reactions
544 Views
(@dryphon)
Posts: 2
New Member
Topic starter
 

Delhi side and other side,

benchmarks don't mean much but we have it

https://components4developers.blog/2021/11/02/http-middleware-benchmarks/

 
Posted : 01/03/2023 2:39 pm
Jon Lennart Aasenden
(@tao4all)
Posts: 44
Member Admin
 

I have seen those before, but without any example code it sadly becomes meaningless. It also depends wildly on the platform, Linux, Windows and MacOS have different server core implementations.

Keep in mind that node.js is just one of the runtimes out there. A much faster alternative is Deno (  https://deno.land/ ), which (based on the latest benchmarks) is over 30% faster than node.js. Deno have a few differences in module names (e.g http module) so you cant just grab a node.js server and run it without a few minor changes.

When version 1.0 is out I will spend some time getting Deno support going in QTX, which blows Delphi out of the water without breaking a sweat.

But the point of node.js is not about being the latest and greatest, but rather about infrastructure and portability. You cant take a Delphi .exe and copy it over to a RISC-V computer and expect it to run. This however is the reality of JSVM based systems. When you add Docker and Kubernetes to that equation, together with PM2 and established web dashboard monitoring and cloud scaling -- suddenly that http.sys server written in a native language becomes somewhat meaningless.

I wrote a small article on this here:
https://www.patreon.com/posts/node-js-or-back-79374779

This post was modified 2 years ago by Jon Lennart Aasenden
 
Posted : 06/03/2023 7:11 pm
(@dryphon)
Posts: 2
New Member
Topic starter
 

I trust Kim with benchmarks.
Of course, portability in node.js is a very good feature.
The node.js server architecture is trying to tempt me. I won't push it aside in the long run.
On the other hand, it is more enjoyable for me to make a similar structure with kbmmw in the x86 architecture, which is the most used in my own customers.

 
Posted : 07/03/2023 3:29 pm
Jon Lennart Aasenden
(@tao4all)
Posts: 44
Member Admin
 

Trust has nothing to do with it, I am sure Kim has done a great job. Just like there are different ways of doing server-code in Delphi (Indy, http.sys, Synapse et-al) there are various options for node.js as well.

However, Deno (which is an alternative to node.js) is over 100% faster than node.js, which easily puts the Deno JSVM above Delphi in this matter:
https://deno.land/images/lp/benchmark@lg.avif?__frsh_c=nkecyd6ak410

But the point of JSVM is not a pissing-contest with Delphi so to speak, but rather to be a tool in the toolbox of Delphi developers. There will be cases where a Delphi solution is the best option, but there will also be situations where node.js will work better. Or Python or ASP .net for that matter.

The whole fanclub mentality and tribalism that each language following seem to fall into, is quite frankly counterproductive in 2023. There was a time when all you needed was Delphi, and lord knows I remember those days well -- but sadly that was decades ago. We now live in a reality where a developer must master different technologies in the marketplace.

The entire point of QTX is not to somehow be better than Delphi; QTX is made with Delphi, so that would be absurd. The point of QTX is to carve out a path that enables Delphi developers to quickly and easily work with web technology - repurposing their existing skillset.

If Web is your target you can spend months learning TypeScript, spend weeks knocking things out in raw JS -- or write Object Pascal that you already know and love - and obtain the same outcome. I would say better outcome, because the RTL provides ready-to-use solutions to things that are quite difficult to do in vanilla JS (and thus rarely seen in the JavaScript world).

Take something simple, like working with binary data. In Delphi we are used to working with streams, buffers and direct access to bits and bytes. JS is quite a different story, and raw memory allocation and manipulation is often costly (in terms of speed) and must be routed through a typed view on top of an untyped memory segment. Most JS developers write damn sloppy code when dealing with this and dont think about optimization at all.

In QTX you have streams, buffers and easy datatype conversion as a part of the RTL which has been optimized with lookup tables whenever possible (read: damn fast). Getting the bytes for an integer, float or string is just a matter of calling one of the class methods in TDataTypeConverter. The same is true for arrays, streams, node.js buffers (which are special) and ordinary JSVM untyped buffers.

Allocating a memory block in QTX is just a matter of creating a TQTXBuffer object and invoking the Allocate() method. Moving data between streams, buffer objects and the JSVM native types is seamless and virtually instantaneous.

So QTX is not in competition with Delphi, but rather an example of what Delphi is capable of 🙂

This post was modified 2 years ago 3 times by Jon Lennart Aasenden
 
Posted : 11/03/2023 1:27 pm
dryphon reacted
Share: