DEV Community: Oleksandr Viktor

🚀 Running Background Jobs in Blazor WASM with WJb (No Backend Required)

Oleksandr Viktor — Mon, 01 Jun 2026 11:55:42 +0000

🚀 Running Background Jobs in Blazor WASM with WJb (No Backend Required)

Background processing usually implies servers, queues, workers… and complexity.

But what if you could run job processing entirely in the browser — with tracking, retries, and cancellation — using a clean API?

That’s exactly what WJb enables.

In this article, I’ll show a simple but powerful demo of WJb running inside Blazor WebAssembly, where jobs are:

✅ Queued with one click
✅ Tracked in real-time
✅ Cancelled or retried from the UI

🧠 What is WJb?

WJb is a lightweight job engine designed for simplicity:

Minimal API surface
Clear job lifecycle (Queued → Processing → Completed/Failed/Cancelled)
Built-in progress tracking
Retry & cancellation support
Works even in WASM (no server required)

🎯 The Demo

The UI is extremely simple:

A Run Demo Job button
A table showing:
- Job ID
- Status
- Progress
- Message
- Attempts
- Actions (Cancel / Retry)

Here’s the core Razor page:

@page "/"

@using WJb.Abstractions
@using WJb.Core
@using WJb.Demo.Wasm.Actions

@inject IJobEngine Engine

▶️ Starting a Job

Enqueueing a job is just one line:

private void Start()
{
    Engine.Enqueue<DemoAction, DemoPayload>(
        new DemoPayload
        {
            DelayMs = 5000,
            Text = "Done ✅"
        });
}

That’s it.

No queue setup.

No worker service.

No background host.

Just enqueue and go.

🔄 Real-Time UI Updates

WJb exposes a simple event:

protected override void OnInitialized()
{
    Engine.Changed += HandleChanged;
    tasks = Engine.GetAll().ToList();
}

private void HandleChanged()
{
    InvokeAsync(() =>
    {
        tasks = Engine.GetAll().ToList();
        StateHasChanged();
    });
}

Whenever a job updates (progress/status), the UI refreshes automatically.

📊 Job State Rendering

Each job comes with a state object:

t.State.Status
t.State.Progress
t.State.Message
t.State.Attempts

Rendering status is clean and expressive:

<span class="badge @(t.State.Status switch
{
    JobStatus.Processing => "bg-primary",
    JobStatus.Completed => "bg-success",
    JobStatus.Failed => "bg-danger",
    JobStatus.Cancelled => "bg-danger",
    _ => "bg-secondary"
})">

And progress is just a Bootstrap bar:

<div class="progress-bar"
     style="width:@t.State.Progress%">
    <small>@t.State.Progress%</small>
</div>

✋ Cancel & Retry

WJb supports job control out of the box:

private void Retry(string id) => Engine.Retry(id);
private void Cancel(string id) => Engine.Cancel(id);

UI logic:

@if (t.State.Status is JobStatus.Queued or JobStatus.Processing)
{
    <button @onclick="() => Cancel(t.JobId)">❌</button>
}
else if (t.State.Status is JobStatus.Failed or JobStatus.Cancelled)
{
    <button @onclick="() => Retry(t.JobId)">🔄</button>
}

🧩 The Interesting Part: It Runs in WASM

This is where things get fun.

All of this works:

✅ Without ASP.NET backend
✅ Without queues like RabbitMQ
✅ Without hosted services

The job engine runs inside the browser runtime.

This makes it perfect for:

Client-side automation
Long-running UI tasks
Offline-first applications
Interactive demos and tooling

💡 Why This Matters

Most job systems are:

Heavy
Infrastructure-dependent
Hard to integrate into UI

WJb flips that:

Traditional Jobs	WJb
Requires backend	Works in WASM
Worker services	In-process engine
Complex setup	Simple API
Limited UI integration	Built for UI

🔥 Key Takeaways

WJb gives you background jobs without infrastructure
Blazor WASM can handle real-time job processing
The API is intentionally minimal:
- Enqueue
- Retry
- Cancel
- GetAll
UI integration is trivial via Engine.Changed

🚀 Final Thoughts

This demo is small, but the idea is powerful:

Background processing doesn’t have to mean backend complexity.

With WJb, you can build responsive, controllable job workflows in the browser.

WJb: Explicit Background Jobs for .NET (Near v1.0)

Oleksandr Viktor — Tue, 28 Apr 2026 10:23:29 +0000

WJb: Explicit Background Jobs for .NET (Near v1.0)

Background processing in .NET often starts simple — and quietly becomes complex.

Retries appear where you did not expect them.

Execution happens “somewhere in the background”.

Workflows grow implicit behavior few people fully understand.

WJb was created as a response to that drift.

As the project approaches v1.0, this article explains what WJb is, what it deliberately is not, and why its design looks different from most background job frameworks.

The Problem WJb Tries to Solve

Many background job frameworks optimize for convenience:

automatic retries
implicit pipelines
hidden orchestration
dynamic runtime behavior

These features are useful — until background execution becomes core business logic.

At that point, questions become difficult to answer:

Why did this job run?
Why did it retry?
What state did it operate on?
What decides the next step?

WJb takes a different stance:

If background jobs are part of your domain, their behavior must be explicit and predictable.

Core Design Principles

WJb is built around a small number of firm rules.

1. Queue‑First, Always

Nothing executes immediately.

Every unit of work:

is serialized into a job payload
enters a queue explicitly
is processed later by a worker

This establishes a hard boundary between intent and execution.

request work → enqueue → execute later

No method call ever causes hidden execution.

2. Explicit Execution Model

WJb does not provide:

automatic retries
implicit continuation
background pipelines
workflow engines

If a job continues, it does so because code explicitly enqueued the next job.

await jobs.EnqueueJobAsync(nextJob);

Routing belongs to actions, not infrastructure.

3. Immutable Snapshots

Execution in WJb operates on immutable snapshots:

action registries are built deterministically
snapshots are replaced atomically
readers never observe partial state

This model avoids synchronization complexity and makes reasoning about concurrency trivial.

4. Actions Own Their Lifecycle

In WJb:

infrastructure executes
domain code decides

Actions:

read metadata
perform work
optionally enqueue the next job

Infrastructure never orchestrates workflows or interprets intent.

A Minimal Example

var job = await jobs.CompactAsync(
    "hello",
    new { name = "World" });

await jobs.EnqueueJobAsync(job);

That is all it takes to enqueue work.

Execution happens:

when the host starts
when the processor consumes the queue
with no hidden steps

Workflow Example (Explicit by Design)

fib-start → fib-build

The continuation is not implicit.

The first action decides explicitly:

await jobs.EnqueueJobAsync(nextJob);

No framework magic.

No pipeline inference.

No hidden guarantees.

Performance Without Tricks

Despite its explicit design, WJb is fast — very fast.

Recent baseline benchmarks (Free edition):

~830k jobs/sec single‑thread enqueue
~1.9M jobs/sec multi‑thread enqueue (20 threads)
✅ strict FIFO within priority
✅ strict priority precedence

These numbers come without unsafe code, without custom schedulers, and without sacrificing correctness.

Performance is a natural outcome of the architecture — not a special optimization step.

What WJb Intentionally Does Not Do

WJb is not trying to replace everything.

It deliberately avoids:

delivery guarantees
persistent storage by default
retries or backoff strategies
distributed coordination
dynamic workflow engines

These concerns belong either:

to hosting infrastructure
or to explicit domain code

WJb’s job is to remain transparent and predictable.

Free Edition Today, v1.0 Tomorrow

As of v0.29, the Free API is frozen.

That means:

public contracts are stable
documented behavior matches runtime behavior
samples and tests reflect real execution

The next step toward v1.0 is real‑world usage, not feature expansion.

v1.0 will not mean “more features”.

It will mean confidence.

Who WJb Is For

WJb is for engineers who:

design long‑living systems
operate production infrastructure
value explicit behavior over automation
want background code to behave like foreground code

If convenience tooling worked for your case — keep using it.

If you ever said “I want to see exactly what happens” — WJb may be for you.

Closing Thoughts

WJb does not try to be clever.

It tries to be honest.

Honest about:

when work runs
why it runs
what state it sees
and what happens next

As the project moves toward v1.0, that principle remains unchanged.

Repository:

👉 https://github.com/UkrGuru/WJb

WJb 0.28.0 Released 🚀

Oleksandr Viktor — Thu, 23 Apr 2026 08:36:03 +0000

WJb 0.28.0 is now available on NuGet.
This release is focused on stability and correctness, especially for long‑running and scheduled workloads:

Improved internal execution reliability
Better cancellation behavior during delays and iterations
Expanded unit test coverage for worker and scheduler logic
No breaking changes

If you’re using WJb for background jobs or scheduled processing, this release strengthens the foundations without requiring code changes.
👉 NuGet: https://www.nuget.org/packages/WJb/0.28.0

Serious question: at this point… who still needs it faster? 🚀

Oleksandr Viktor — Mon, 20 Apr 2026 13:32:27 +0000

Benchmarking WJb: Measuring Raw Background Job Throughput in .NET

Oleksandr Viktor — Sun, 19 Apr 2026 08:32:23 +0000

Benchmarking WJb: Measuring Raw Background Job Throughput in .NET

When building a background job system, performance questions appear almost immediately:

How fast can I enqueue jobs?
Does it scale with concurrent producers?
What happens when payloads are not trivial?
Are delayed and timer jobs expensive?

To answer these questions early, WJb ships with a dedicated benchmark project:

WJb.Benchmarks [github.com]

This article explains what exactly is measured, how the benchmarks are structured, and what the numbers really mean.

Why Benchmark Enqueue Speed First?

WJb is designed as a lightweight, explicit background job engine.

Unlike full orchestration systems, WJb deliberately avoids:

Persistent storage by default
Distributed locks
Retries, dashboards, or schedulers baked into the core

That makes enqueue throughput a critical foundational metric.

If placing jobs into the system is slow or unpredictable, everything else scales poorly — regardless of how fast job execution later becomes.

What Is WJb.Benchmarks?

WJb.Benchmarks is a standalone console benchmark application designed to answer one simple question:

How fast can WJb prepare and enqueue jobs under different conditions?

The benchmark project lives under the test folder and is intentionally isolated from production code to keep results clean and reproducible. [github.com]

Benchmark Scenarios

The benchmark suite focuses on enqueue-only performance and includes four core scenarios:

1. Single-threaded enqueue

Measures raw throughput when jobs are enqueued sequentially from a single producer.

This represents:

Simple applications
Low-contention background usage
Baseline overhead of job creation + JSON compaction

Why it matters:
Single-thread speed reflects framework overhead, not threading tricks.

2. Multi-threaded enqueue (concurrent producers)

Uses multiple threads enqueueing jobs simultaneously.

This simulates:

Web APIs enqueueing background work
Message-driven systems
Burst workloads under pressure

The goal here is scalability, not just raw numbers.

3. Heavy JSON payload enqueue

Jobs rarely carry empty payloads in real systems.

This benchmark measures:

JSON serialization overhead
JsonObject compaction cost
Memory pressure from larger payloads

The payload is intentionally heavy to reveal realistic performance drops instead of optimistic results.

4. Delayed / timer job enqueue

Delayed jobs often involve:

Extra metadata
Timer coordination
Scheduling logic

This benchmark isolates enqueue cost only, without waiting for execution.

Benchmark Setup

The benchmarks are intentionally boring — and that’s a feature.

Action implementation: minimal IAction returning Task.CompletedTask
Execution: enqueue only (no worker execution measured)
Configuration: Release build
Runtime: modern .NET
Environment: standard developer machine

No database.

No persistence.

No background threads executing jobs.

This keeps results focused and repeatable.

Sample Results

A representative benchmark run looks like this:

WJb Performance Benchmark Suite
==================================
[Multi-threaded Enqueue]
200,000 jobs from 8 threads → ~320 ms
≈ 600k+ jobs/sec

[Single-thread Enqueue]
100,000 jobs → ~180 ms
≈ 500k+ jobs/sec

[Heavy JSON Payload]
20,000 jobs → ~400 ms
≈ 50k jobs/sec

[Delayed / Timer Jobs]
10,000 jobs → ~30 ms
≈ 330k jobs/sec

⚠️ Exact numbers will vary per machine. The trend and scaling behavior are what matter.

How to Read These Numbers (Correctly)

These benchmarks do not measure job execution.

They measure:

Job compaction
JSON serialization
Internal queueing
Thread contention behavior

Real-world throughput will depend on:

The work your jobs perform
Worker concurrency
Machine resources
Whether persistence is added later

But high enqueue performance is still valuable because it ensures:

✅ predictable latency under load

✅ minimal overhead per job

✅ headroom for future features

Why This Approach Works

Many job systems optimize dashboards, retries, or storage first.

WJb does the opposite:

Build a fast, explicit, predictable core — then layer complexity consciously.

WJb.Benchmarks exists to validate that core continually, not once.

Run It Yourself

Clone the repository and run the benchmark project directly:

dotnet run -c Release

Because it’s a plain console app, no infrastructure setup is required.

Repository:
https://github.com/UkrGuru/WJb/tree/main/test/WJb.Benchmarks [github.com]

Final Thoughts

Benchmarks don’t make software good — discipline does.

But a lightweight job engine that can enqueue hundreds of thousands of jobs per second provides a solid foundation for:

APIs
Workers
Schedulers
Workflow engines

WJb.Benchmarks is not about bragging rights — it’s about knowing the cost of every abstraction you add.

If that philosophy resonates with you, WJb is worth exploring further.

WJb Hits 700k+ Jobs/sec: Benchmarking the New Lightweight Background Job Library for .NET

Oleksandr Viktor — Wed, 15 Apr 2026 12:54:50 +0000

WJb Hits 700k+ Jobs/sec: Benchmarking the New Lightweight Background Job Library for .NET

Just hours after its release, a brand-new .NET background job library is already showing impressive performance.

Meet WJb — a minimal, flexible, and explicit background job execution library built by UkrGuru (Oleksandr Viktor). Released today (April 15, 2026), WJb focuses on simplicity, predictability, and control instead of heavy magic or complex infrastructure.

Why WJb?

While mature solutions like Hangfire and Quartz.NET are powerful, sometimes you just want something lightweight with:

Priority-based queues
JSON payloads
Cron-based scheduling
Clean DI and IHostedService integration
No bloat, no hidden behaviors

WJb promises exactly that: explicit, controllable background job processing.

The Benchmark Suite

I created a dedicated benchmark console app to stress-test WJb right after installation. The suite measures:

Single-threaded enqueue throughput
Multi-threaded enqueue scaling (realistic producer load)
Heavy JSON payload overhead
Delayed/timer job enqueue speed

Benchmark Setup

Library: WJb v0.26.0
.NET: Latest (Release configuration)
Hardware: Standard development machine
Action: Minimal IAction implementation (just returns Task.CompletedTask)

Results (v9 run)

WJb Performance Benchmark Suite v9
==================================

WJb initialized.

[Multi-threaded Enqueue] 200,000 jobs from 8 threads
    → 323.74 ms  |  617,771 jobs/sec

[Single-thread Enqueue] 100,000 jobs
    → 186.07 ms  |  537,419 jobs/sec

[Heavy JSON Payload] 20,000 jobs
    → 404.28 ms  |  49,471 jobs/sec

[Delayed/Timer Jobs] 10,000 jobs
    → 29.66 ms  |  337,187 jobs/sec

✅ Benchmark suite completed.

Highlights:

Multi-threaded enqueue reached over 617k jobs per second — excellent scaling under concurrent load.
Single-threaded performance stayed consistently above 500k jobs/sec.
Heavy JSON payloads showed the expected drop due to serialization (still very respectable at ~49k/sec).
Delayed jobs performed well even when using the standard enqueue path.

What These Numbers Mean

These results are enqueue-only benchmarks (measuring how fast we can prepare and queue jobs). Real-world throughput will also depend on:

How heavy your job actions are
Number of worker threads configured
Database/storage backend (if persistence is added later)
Machine resources

Still, hitting 600k+ enqueue operations per second on day one is very promising for a lightweight library.

The Benchmark Code

You can find the full benchmark project structure and code in my repository (link will be added after publishing). The core pattern follows WJb’s official HelloWJb sample:

Register actions with services.AddWJb(actions)
Use IJobProcessor + CompactAsync() + EnqueueJobAsync()
Keep actions simple and idempotent (as recommended by the library)

Final Thoughts

WJb is extremely young (literally released today), yet it already shows strong fundamentals:

Clean, minimal API
Great raw enqueue performance
Clear focus on predictability over automation

If you need lightweight background jobs without pulling in a full orchestrator, WJb looks like a solid contender worth watching.

Tags:

.NET, BackgroundJobs, Performance, C#, OpenSource, Async

NPoco vs UkrGuru.Sql: When Streaming Beats Buffering

Oleksandr Viktor — Thu, 02 Apr 2026 18:29:25 +0000

When we talk about database performance in .NET, we often compare ORMs as if they were interchangeable. In practice, the API shape matters just as much as the implementation.

In this post, I benchmark NPoco and UkrGuru.Sql using BenchmarkDotNet, focusing on a very common task: reading a large table from SQL Server. The interesting part is not which library wins, but why the numbers differ so much.

TL;DR: Streaming rows with IAsyncEnumerable<T> is faster, allocates less, and scales better than loading everything into a list.

Test Scenario

The setup is intentionally simple and realistic.

Database: SQL Server
Table: Customers
Dataset: SampleStoreLarge (large enough to stress allocations)
Columns:
- CustomerId
- FullName
- Email
- CreatedAt

All benchmarks execute the same SQL:

SELECT CustomerId, FullName, Email, CreatedAt FROM Customers

No filters, no projections — just raw read performance.

Benchmark Code

using BenchmarkDotNet.Attributes;
using Microsoft.Data.SqlClient;
using NPoco;
using UkrGuru.Sql;

public class SqlBenchmark
{
    private const string ConnectionString =
        "Server=(local);Database=SampleStoreLarge;Trusted_Connection=True;TrustServerCertificate=True;";

    private const string CommandText =
        "SELECT CustomerId, FullName, Email, CreatedAt FROM Customers";

    [Benchmark]
    public async Task<int> NPoco_LoadList()
    {
        using var connection = new SqlConnection(ConnectionString);
        await connection.OpenAsync();

        using var db = new Database(connection);

        var list = await db.FetchAsync<Customer>(CommandText);
        return list.Count;
    }

    [Benchmark]
    public async Task<int> UkrGuru_LoadList()
    {
        await using var connection = await DbHelper.CreateConnectionAsync(ConnectionString);

        var list = await connection.ReadAsync<Customer>(CommandText);
        return list.Count();
    }

    [Benchmark]
    public async Task<int> UkrGuru_StreamRows()
    {
        int count = 0;

        await using var command = await DbHelper.CreateCommandAsync(
            CommandText,
            connectionString: ConnectionString);

        await foreach (var _ in command.ReadAsync<Customer>())
            count++;

        return count;
    }
}

All benchmarks were run in Release mode with BenchmarkDotNet.

Results (Execution Time)

Method	Mean	StdDev	Median
NPoco_LoadList	8.23 ms	0.33 ms	8.22 ms
UkrGuru_LoadList	5.30 ms	0.57 ms	5.34 ms
UkrGuru_StreamRows	3.29 ms	0.14 ms	3.22 ms

At first glance, streaming is already ~2.5× faster than NPoco. But the real story starts when we look at memory.

Results (Memory & GC)

Method	Gen0	Gen1	Gen2	Allocated
NPoco_LoadList	367	258	109	4.39 MB
UkrGuru_LoadList	203	188	70	2.33 MB
UkrGuru_StreamRows	164	–	–	2.08 MB

This table explains almost everything.

What’s Actually Being Measured?

NPoco_LoadList

Uses FetchAsync<T>()
Fully materializes a List<Customer>
Allocates buffers and intermediate objects

✅ Idiomatic NPoco usage

❌ No streaming support

NPoco optimizes for developer productivity, not minimal allocations. That’s a valid trade‑off, but it shows up clearly in GC pressure.

UkrGuru_LoadList

Also builds a full list
Uses a leaner mapping pipeline
Roughly half the allocations of NPoco

✅ Same algorithm as NPoco

✅ Less overhead

This is a fair apple‑to‑apple comparison with NPoco’s approach.

UkrGuru_StreamRows

Uses IAsyncEnumerable<T>
Processes rows one at a time
No list allocation
No Gen2 collections

✅ True async streaming

✅ Lowest latency

✅ Most stable GC behavior

This is not a micro‑optimization — it’s a different execution model.

Why Streaming Wins

The biggest improvement is not raw speed — it’s memory behavior.

Fewer allocations
Almost no object promotion
No Gen2 collections

That matters a lot under real load: ASP.NET requests, background workers, message consumers, etc.

Streaming doesn’t just run faster — it scales better.

About Fairness

This benchmark is not trying to prove that one ORM is “better” than another.

It compares three distinct patterns:

Buffered list materialization (NPoco)
Buffered list materialization with fewer abstractions
True async streaming

Comparing streaming to buffering is not “ORM vs ORM” — it’s algorithm vs algorithm.

When Should You Use Each?

Use NPoco when:

You want simple, expressive data access
Loading lists is acceptable
Developer time matters more than raw throughput

Use streaming (e.g. UkrGuru.Sql) when:

Result sets are large
Latency and GC pressure matter
You want full control over execution

Final Thoughts

Benchmarks don’t just measure libraries — they measure abstractions and APIs.

If your workload is dominated by large reads, switching from buffered lists to async streaming can cut both execution time and memory pressure dramatically.

Choose the tool that matches your data access pattern, not just the one you’re used to.

🚀 Simplify ADO.NET Stream Rows ...

Oleksandr Viktor — Wed, 01 Apr 2026 10:04:53 +0000

SqlLoadListBenchmark – Simple ADO.NET vs UkrGuru.Sql Demo

This demo shows how ADO.NET and UkrGuru.Sql perform the same work using different coding styles, along with benchmark results.

🖼 1. LoadList Demo (ADO.NET vs UkrGuru)

ADO.NET_LoadList

public async Task<int> ADONET_LoadList()
{
    var list = new List<Customer>();
    using var conn = new SqlConnection(ConnectionString);
    await conn.OpenAsync();
    using var cmd = new SqlCommand(CommandText, conn);
    using var reader = await cmd.ExecuteReaderAsync();

    while (await reader.ReadAsync())
    {
        list.Add(new Customer
        {
            CustomerId = reader.GetInt32(0),
            FullName   = reader.GetString(1),
            Email      = reader.GetString(2),
            CreatedAt  = reader.GetDateTime(3)
        });
    }

    return list.Count;
}

UkrGuru_LoadList

public async Task<int> UkrGuru_LoadList()
{
    await using var connection = await DbHelper.CreateConnectionAsync(ConnectionString);
    var list = await connection.ReadAsync<Customer>(CommandText);
    return list.Count();
}

🖼 2. StreamRows Demo (ADO.NET vs UkrGuru)

ADO.NET_StreamRows

public async Task<int> ADONET_StreamRows()
{
    int count = 0;
    await foreach (var row in StreamCustomersAsync())
        count++;

    return count;

    async IAsyncEnumerable<Customer> StreamCustomersAsync(
        [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        using var conn = new SqlConnection(ConnectionString);
        await conn.OpenAsync(cancellationToken);
        using var cmd = new SqlCommand(CommandText, conn);
        using var reader = await cmd.ExecuteReaderAsync(
            System.Data.CommandBehavior.SequentialAccess, cancellationToken);

        while (await reader.ReadAsync(cancellationToken))
        {
            yield return new Customer
            {
                CustomerId = reader.GetInt32(0),
                FullName   = reader.GetString(1),
                Email      = reader.GetString(2),
                CreatedAt  = reader.GetDateTime(3)
            };
        }
    }
}

UkrGuru_StreamRows

public async Task<int> UkrGuru_StreamRows()
{
    int count = 0;
    await using var command =
        await DbHelper.CreateCommandAsync(CommandText, connectionString: ConnectionString);

    await foreach (var item in command.ReadAsync<Customer>())
        count++;

    return count;
}

📊 Benchmark Results

Method	Mean	Error	StdDev
ADONET_StreamRows	2.953 ms	0.0472 ms	0.0441 ms
UkrGuru_StreamRows	3.141 ms	0.0415 ms	0.0407 ms
ADONET_LoadList	4.309 ms	0.0721 ms	0.0675 ms
UkrGuru_LoadList	4.713 ms	0.0908 ms	0.1116 ms

📝 Summary

StreamRows: Both are fast; ADO.NET is slightly faster in this raw sequential benchmark.
LoadList: UkrGuru.Sql is a bit slower in this scenario but provides much cleaner code with far less boilerplate.
Code simplicity vs raw speed:
- ADO.NET = faster, more verbose
- UkrGuru.Sql = cleaner, safer, more maintainable Check it out 👇

🔗 https://github.com/UkrGuru/Sql/tree/main/demos/SqlLoadListBenchmark

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

Oleksandr Viktor — Wed, 25 Mar 2026 14:05:13 +0000

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

When you optimize for real‑world performance, microseconds matter — sometimes nanoseconds matter.

This benchmark compares UkrGuru implementations with Microsoft Copilot‑generated equivalents across common low-level operations: primitives, arrays, serialization, and structs.

The results were surprising — especially considering that Copilot code tends to follow “safe defaults,” while UkrGuru focuses heavily on allocation‑free, branch‑minimal, CPU‑friendly implementation patterns.

This article summarizes the benchmark results and provides a downloadable table for transparency.

📊 Benchmark Summary

The table below shows Mean execution time, Error, StdDev, Rank, and Memory Allocation.

Lower Mean and Rank are better.

Lower Allocated (ideally 0 bytes) is also better.

| Method        | Mean        | Error      | StdDev    | Rank | Gen0   | Allocated |
|-------------- |------------:|-----------:|----------:|-----:|-------:|----------:|
| Ukr_Bool      |   0.9436 ns |  0.0552 ns | 0.0030 ns |    2 |      - |         - |
| Cop_Bool      |   5.5047 ns |  0.2465 ns | 0.0135 ns |    4 |      - |         - |
| Ukr_Int       |   5.4953 ns |  0.6840 ns | 0.0375 ns |    4 |      - |         - |
| Cop_Int       |  12.9375 ns |  0.1144 ns | 0.0063 ns |    8 |      - |         - |
| Ukr_Double    |  23.5338 ns |  0.9775 ns | 0.0536 ns |   13 |      - |         - |
| Cop_Double    |  22.5574 ns |  1.4858 ns | 0.0814 ns |   12 |      - |         - |
| Ukr_Decimal   |  29.7762 ns |  0.9910 ns | 0.0543 ns |   15 |      - |         - |
| Cop_Decimal   |  30.6302 ns |  2.3973 ns | 0.1314 ns |   16 |      - |         - |
| Ukr_Guid      |  12.7784 ns |  0.3671 ns | 0.0201 ns |    7 |      - |         - |
| Cop_Guid      |  12.1073 ns |  1.8873 ns | 0.1035 ns |    6 |      - |         - |
| Ukr_DateOnly  |  52.5456 ns |  2.6977 ns | 0.1479 ns |   17 |      - |         - |
| Cop_DateOnly  |  57.3368 ns |  2.9485 ns | 0.1616 ns |   18 | 0.0036 |      48 B |
| Ukr_TimeOnly  | 109.1004 ns |  1.9878 ns | 0.1090 ns |   20 |      - |         - |
| Cop_TimeOnly  | 119.5629 ns | 10.2523 ns | 0.5620 ns |   21 | 0.0041 |      56 B |
| Ukr_TimeSpan  |  52.4028 ns |  1.9116 ns | 0.1048 ns |   17 |      - |         - |
| Cop_TimeSpan  |  62.9908 ns | 15.9374 ns | 0.8736 ns |   19 | 0.0030 |      40 B |
| Ukr_ByteArray |  15.5711 ns |  0.7072 ns | 0.0388 ns |    9 | 0.0055 |      72 B |
| Cop_ByteArray |  15.7549 ns |  0.7830 ns | 0.0429 ns |   10 | 0.0055 |      72 B |
| Ukr_CharArray |   0.9538 ns |  0.3159 ns | 0.0173 ns |    3 |      - |         - |
| Cop_CharArray |   0.8838 ns |  0.1034 ns | 0.0057 ns |    1 |      - |         - |
| Ukr_Serialize |   5.6374 ns |  0.6384 ns | 0.0350 ns |    5 | 0.0043 |      56 B |
| Cop_Serialize |  12.0702 ns |  0.5457 ns | 0.0299 ns |    6 | 0.0067 |      88 B |
| Ukr_Enum      |  24.4368 ns |  2.8392 ns | 0.1556 ns |   14 | 0.0018 |      24 B |
| Cop_Enum      |  21.3234 ns |  1.0134 ns | 0.0555 ns |   11 | 0.0043 |      56 B |

🔥 Key Observations

1. UkrGuru wins most primitive operations

Especially in:

Bool
Int
Decimal
TimeSpan

These results highlight extremely efficient, allocation‑free handling of simple .NET types.

2. Copilot sometimes wins — but only occasionally

There are categories where Copilot’s code came out slightly ahead (e.g., CharArray).

This is good — benchmarks should challenge both sides.

It makes the overall results more meaningful.

3. Memory allocations reveal the biggest gap

In several operations, Copilot-generated code allocates:

48 B in DateOnly
56 B in TimeOnly
40 B in TimeSpan
88 B in Serialize
56 B in Enum conversions

Meanwhile, most UkrGuru methods remain 0‑allocation, which is critical for:

high-throughput APIs
microservices
real-time pipelines
game loops
tight CPU‑bound workloads

🤖 Why Copilot Can’t Keep Up

Microsoft Copilot is great at generating safe general-purpose code, but not specialized for:

nanosecond‑level optimization
allocation‑free pipelines
branch elimination
struct‑level micro-optimizations
IL-friendly patterns

That’s exactly where UkrGuru excels — handcrafted low-level performance-oriented code.

🏁 Conclusion

This benchmark doesn’t say “Copilot is bad.”

It simply shows that generic AI-generated code cannot outperform hand‑tuned, purpose-built UkrGuru implementations.

If your application needs maximum performance with minimal allocations — UkrGuru wins.

📦 Want to reproduce the benchmark?

Full source code, including benchmark classes and configuration, is available here:

👉 https://github.com/UkrGuru/Sql/tree/main/dev/ResultsBench/ResultsBench

updated for WJb 0.25.0-beta

Oleksandr Viktor — Tue, 13 Jan 2026 05:53:17 +0000

Basics (Getting Started) with WJb

Oleksandr Viktor ・ Dec 17 '25

#programming #webdev #ai

https://github.com/UkrGuru/Sql - simple and the best

Oleksandr Viktor — Wed, 08 Oct 2025 19:51:55 +0000

GitHub - UkrGuru/Sql

Contribute to UkrGuru/Sql development by creating an account on GitHub.

github.com

Try UkrGuru.Sql with New Optimized `Results.Parse`

Oleksandr Viktor — Thu, 29 May 2025 05:55:41 +0000

Here’s a short article with the requested title:

Try UkrGuru.Sql with New Optimized `Results.Parse`

The latest release of UkrGuru.Sql introduces a powerful enhancement: an optimized Results.Parse method designed to streamline how developers handle SQL query results in .NET applications.

🚀 What’s New?

The new Results.Parse method significantly improves performance and usability by:

Faster parsing of SQL result sets into .NET objects
Reduced memory footprint for large datasets
Improved error handling and type safety
Simplified syntax for cleaner, more maintainable code

📊 Benchmark Results

Method	Mean	Error	StdDev	Gen0	Allocated
ResultsNew_ToStr	541.0 ns	66.87 ns	3.67 ns	0.0830	1096 B
ResultsOld_ToStr	2,195.4 ns	177.93 ns	9.75 ns	0.1411	1872 B
ResultsNew_FromStr	1,021.9 ns	85.43 ns	4.68 ns	0.0629	840 B
ResultsOld_FromStr	1,521.0 ns	166.13 ns	9.11 ns	0.0515	696 B

These results show a clear performance gain in both serialization and deserialization with the new implementation.

private static readonly object?[] _oInputs =
[
    null,
    DBNull.Value,
    false,
    true,
    byte.MaxValue,
    short.MaxValue,
    int.MaxValue,
    long.MaxValue,
    float.MaxValue,
    double.MaxValue,
    decimal.MaxValue,
    DateOnly.MaxValue,
    DateTime.MaxValue,
    DateTimeOffset.MaxValue,
    TimeOnly.MaxValue,
    TimeSpan.MaxValue,
    Guid.Empty,
    'A',
    "AV & ASD",
    Encoding.UTF8.GetBytes("AV & ASD"),
    new char[] { 'A', 'V', '&', 'A', 'S', 'D' },
    TestEnum.One,
    //new string[] { "A", "V", "&", "A", "S", "D" },
    //new NamedType { Id = 1, Name = "Test" }
];

[Benchmark]
public object?[] ResultsNew_ToStr()
{
    object?[] values = new object?[_oInputs.Length];

    for (var i = 0; i < values.Length; i++)
    {
        values[i] = ResultsNew.Parse<string?>(_oInputs[i]);
        //Console.WriteLine(values[i]);
    }

    return values;
}


[Benchmark]
public object?[] ResultsNew_FromStr()
{
    var index = 0;
    object?[] values = new object?[_sInputs.Length];

    values[index++] = ResultsNew.Parse<bool?>(_sInputs[0]); // null
    values[index++] = ResultsNew.Parse<bool>(_sInputs[1]); // false
    values[index++] = ResultsNew.Parse<bool>(_sInputs[2]); // true
    values[index++] = ResultsNew.Parse<byte>(_sInputs[3]); // byte
    values[index++] = ResultsNew.Parse<short>(_sInputs[4]); // short
    values[index++] = ResultsNew.Parse<int>(_sInputs[5]); // int
    values[index++] = ResultsNew.Parse<long>(_sInputs[6]); // long
    values[index++] = ResultsNew.Parse<float>(_sInputs[7]); // float
    index++; //values[index++] = ResultsNew.Parse<double>(_sInputs[8]); // double
    values[index++] = ResultsNew.Parse<decimal>(_sInputs[9]); // decimal
    values[index++] = ResultsNew.Parse<DateOnly>(_sInputs[10]); // DateOnly
    values[index++] = ResultsNew.Parse<DateTime>(_sInputs[11]); // DateTime
    values[index++] = ResultsNew.Parse<DateTimeOffset>(_sInputs[12]); // DateTime
    values[index++] = ResultsNew.Parse<TimeOnly>(_sInputs[13]); // TimeOnly
    values[index++] = ResultsNew.Parse<TimeSpan>(_sInputs[14]); // TimeOnly
    values[index++] = ResultsNew.Parse<Guid>(_sInputs[15]); // Guid
    values[index++] = ResultsNew.Parse<char>(_sInputs[16]); // char
    values[index++] = ResultsNew.Parse<string>(_sInputs[17]); // string
    values[index++] = ResultsNew.Parse<byte[]>(_sInputs[18]); // byte[]
    values[index++] = ResultsNew.Parse<char[]>(_sInputs[19]); // char[]
    values[index++] = ResultsNew.Parse<TestEnum>(_sInputs[20]); // enum
    //values[index++] = ResultsNew.Parse<string[]>(_sInputs[21]); // string[]
    //values[index++] = ResultsNew.Parse<NamedType>(_sInputs[22]);

    //for (var i = 0; i < values.Length; i++)
    //{
    //    Console.WriteLine(values[i]);
    //}

    return values;
}

🛠️ Why It Matters

Whether you're building APIs, background services, or data-driven applications, the optimized Results.Parse helps you:

Minimize boilerplate code
Improve application responsiveness
Focus more on business logic and less on data plumbing

📦 Ready to Explore?

Check out the package on NuGet and start building smarter, faster, and cleaner SQL-powered .NET apps today.

Would you like this article formatted for a blog post, social media, or a README file?