WJb vs Hangfire vs Quartz: Same Benchmarks, Same Machine
Background job libraries are usually compared by features.
This benchmark compares something simpler:
How fast can they enqueue work?
Repository:
https://github.com/UkrGuru/WJb.Demo/tree/main/benchmark
Benchmarks were implemented separately for:
- WJb
- Hangfire
- Quartz
Using:
- BenchmarkDotNet
- In-memory storage
- No-op jobs/actions
- Equivalent benchmark scenarios
Single Enqueue
Enqueue one job.
| Library | Time | Memory |
|---|---|---|
| WJb | 349 ns | 328 B |
| Quartz | 3.848 μs | 3.08 KB |
| Hangfire | 6.212 μs | 11.46 KB |
Result
- WJb ≈ 11× faster than Quartz
- WJb ≈ 18× faster than Hangfire
EnqueueMany (100,000 Jobs)
Bulk enqueue benchmark.
| Library | Time | Memory |
|---|---|---|
| WJb | 32 ms | 31 MB |
| Hangfire | 743 ms | 1063 MB |
| Quartz | 902 ms | 539 MB |
Result
- WJb ≈ 23× faster than Hangfire
- WJb ≈ 28× faster than Quartz
Parallel Enqueue (100,000 Jobs)
Multiple concurrent producers.
| Library | Best Time |
|---|---|
| WJb | 52 ms |
| Hangfire | 540 ms |
| Quartz | 600 ms |
Memory Usage
100,000 jobs:
| Library | Memory |
|---|---|
| WJb | 31 MB |
| Quartz | 539 MB |
| Hangfire | 1063 MB |
Result
- WJb uses ~17× less memory than Quartz
- WJb uses ~34× less memory than Hangfire
Why WJb?
WJb was designed around a very small execution model:
enqueue
↓
job
↓
action
No dashboard.
No workflow engine.
No implicit pipeline.
Just explicit background jobs.
Reproduce
Source code is included:
WJb.Benchmarks
WJb.Benchmarks.Hangfire
WJb.Benchmarks.Quartz
Run:
dotnet run -c Release
Final Numbers
For these benchmark scenarios:
✅ Fastest enqueue: WJb
✅ Fastest bulk enqueue: WJb
✅ Fastest parallel enqueue: WJb
✅ Lowest memory usage: WJb
Benchmark scenarios are intentionally small, reproducible, and focused on enqueue performance.
Additional scenarios will be added only when equivalent implementations exist for all compared libraries.
Top comments (0)