Hyperlambda is Faster than C#

I just measured the performance of a Hyperlambda CRUD read endpoint and compared it to the equivalent C# version built with Entity Framework, IoC, using Data Repository pattern - And believe it or not but Hyperlambda is actually faster.

The difference is not much, but Hyperlambda seems to be consistently performing 3 to 10 percent faster than the equivalent EF solution built with .Net 9. And, I was never able to have the EF version outperform the HL version. The database I used was SQLite Chinook for both solutions. The same physical file may I add.

The test was simple, invoke an HTTP endpoint over and over again in a while loop for 1 minute, and count how many HTTP requests was able to successfully execute. It's a fairly naive test, but the results speaks volumes! You can find the figures from my last run below.

Implementation	OK Count	Duration	Requests/sec
Hyperlambda.	9975	60s	166.25.
C#	9564	60s	159.40

I ran the test multiple times for both projects, and the Hyperlambda version was consistently around 3 to 10 percent faster. You can find my script below if you want to reproduce what I did.

#!/usr/bin/env bash
# Sequential benchmark for a single endpoint on macOS.
# Hits the URL back-to-back for DURATION seconds and counts HTTP 200s.

URL="${1:-http://YOUR_URL_HERE}"
DURATION="${2:-60}"     # seconds
TIMEOUT="${3:-5}"       # per-request timeout (seconds)
WARMUP="${4:-10}"       # warmup requests (not counted)

echo "Endpoint: $URL"
echo "Warmup: $WARMUP requests"
for ((i=0;i/dev/null
done

echo "Benchmarking for ${DURATION}s (sequential requests)…"
count=0
end=$((SECONDS + DURATION))
while [ $SECONDS -lt $end ]; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time "$TIMEOUT" "$URL")
  if [ "$code" = "200" ]; then
    ((count++))
  fi
done

# Print results
rate=$(awk "BEGIN {printf \"%.2f\", $count/$DURATION}")
echo
echo "Results:"
echo "  OK count: $count"
echo "  Duration: ${DURATION}s"
echo "  Rate:     ${rate} req/s"

Exchange the URL in the above bash script, and execute it. At the end of its execution it will give you a count of how many invocations it was able to successfully execute. Like I said, a naive test, but still relevant, and basically tellin you everything you need to know related to performance of Hyperlambda versus C# with EF and "best practices".

The Code

The Hyperlambda code I used for my endpoint was the following.

data.connect:chinook
   data.read
      table:Artist
      limit:10
   return-nodes:x:-/*

5 lines of Hyperlambda code in one file. The C# code I used was about 150 lines of code and was scattered across 11 files, so it's way too much code to show here, but you can download it here if you wish. I created the C# code by going to ChatGPT, pasting in my Hyperlambda code, and giving it the following instruction.

Port this Hyperlambda HTTP endpoint code to C#, and use Data Repository pattern, IoC, Entity Framework, and other best practices

So my C# code probably ended up being similar to 99% of all C# code you've got in your own projects, assuming you're building your C# code using "best practices" and Entity Framework. Which means that although you might find the occassional improvement opportunity in my C# code, it probably resembles most of the projects you are currently working on.

Entity Framework

I could of course prove this by creating a pure ADO.NET solution, but I already know the culprit, and it's Entity Framework. An O/RM library like Entity Framework first of all adds unnecessary complexity. If you're using it "correctly", your domain specific code becomes scattered into dozens of files, where multiple files needs to be edited to make a simple change. In addition EF adds tons of additional unnecessary runtime overhead to allow for "transpiling" between your OO syntax and SQL.

Basically, the Hyperlambda runtime is simply faster than EF!

Just to silence the nay sayers, I added optional paging and sorting to the endpoint, and it ticket in at 171.77 requests per second, which was even an improvement from my original code. This variation can be explained by "expected variations", but the fact that adding these features didn't in any ways reduce the execution speed should be telling. You can see my updated code below.

.arguments
   limit:long
   offset:long
   order:string
   direction:string
data.connect:chinook
   add:x:./*/data.read
      get-nodes:x:@.arguments/*
   data.read
      table:Artist
   return-nodes:x:-/*

11 lines of code in total, in one file. I assume ChatGPT would have added some 100 to 200 additional lines of code for me if I asked it to add these optional arguments to my C# solution, and probably some 3 to 5 additional files. So even with optional paging and sorting, my Hyperlambda endpoint is still 3 to 10 percent faster than my C# solution. In fact, regardless of what I do in Hyperlambda, I'm rarely able to make something that's slower than the equivalent C# code. And for the record, no I do not have caching in my Hyperlambda solution.

Conclusion

The fact that Hyperlambda is faster than C# with EF should be very, very, very embarrassing for the EF team. These guys are some of the smartest developers in the world, working for one of the richest companies on Earth (Microsoft), earning probably half a million each per year in salary - While I started Hyperlambda as a "hobby project", and I created it 100% alone!

I've already written a lot of articles about how C# is roughly 20 times more verbose than Hyperlambda, implying you'll need to physically write 20 times as much code to accomplish something in C# compared to if you were using Hyperlambda. However, the fact that Hyperlambda is also faster, and hence purely logically also probably more scalable, should speak volumes!

This implies that not only are you 20 times more productive if you're using Hyperlambda, but your end solution is also some 5 to 10 percent faster. Implying the following ...

Hyperlambda is simply better than C# (with EF), on everything that can be measured, and everything that is relevant!

Notice, I could perform the same comparison with Python, but since C# with EF is already roughly 7 times faster than the equivalent Python solution, that would not be neccessary. A comparison with PHP of course, as everybody knows, it completely useless since PHP by its nature is 10 to 100 times slower than C#, so it is therefore safe to say the following;

Hyperlambda is the fastest programming language on Earth, assuming you're following "best practices" when developing!

Don't agree with me? Cool, reproduce my example by cloning Magic Cloud and do your own tests! Then come back and have an informed opinion!

Psst, if you want to do a pure ADO.NET test, and paste your SQL directly into the endpoint, then by all means go for it. It will be faster than Hyperlambda, but then your code is also "worst practices" for .Net and C# development. Dapper will also (probably) be a little bit faster, but EF is the by far most popular O/RM library in the world, and probably used in 95% of .Net projects currently being maintained today, so I think the test is highly relevant.