Understanding Qeltrix V1 PoC Performance: Context & Limitations

Source: Dev.to

Critical Context: What This PoC Really Is

This is a Proof‑of‑Concept at its most fundamental level.
It’s not pre‑development, not a prototype, not alpha software. The V1 PoC exists solely to answer one question: “Is this technical approach viable?” The performance measurements help validate that viability, but they don’t represent optimized, production‑ready performance.

PoC Definition

• Purpose: Validate core concept feasibility
• Optimization level: None – deliberately basic
• Code maturity: Foundational validation code
• Performance target: Prove it works, not prove it’s fast

Why V1 Performance Numbers Are Inherently Limited

1. Python Implementation Constraints

The V1 PoC is written in Python, which introduces significant performance overhead:

• Python’s Global Interpreter Lock (GIL)
  • Limits true parallel execution for CPU‑bound operations
  • Only one thread executes Python bytecode at a time
  • ProcessPoolExecutor helps but adds inter‑process communication overhead
• Interpreted vs. Compiled Language Speed
  • Python is typically 10–50× slower than compiled languages like Rust, C, or C++
  • A production implementation in a systems language would show dramatically different performance
  • The same algorithm in Rust or C++ could easily achieve 10–20× higher throughput

2. Test Environment Limitations

Hardware Used: Budget Laptop
The published results come from testing on a budget laptop, not a dedicated testing server or high‑performance workstation. This significantly impacts:

• Available CPU cores and processing power
• Memory bandwidth and cache performance
• Disk I/O speeds
• Overall thermal management

Operating System: Windows

• Windows introduces additional overhead compared to Linux
• Background services and system processes consume resources
• File I/O performance differs from UNIX‑like systems

Concurrent System Load

The test environment runs many other services and applications simultaneously (background system services, development tools, web browsers, system monitoring, antivirus software), reducing the available system resources during testing.

3. PoC Design Limitations

• No Optimization Efforts
  • Code prioritizes clarity and proof‑of‑concept over performance
  • No profiling or performance tuning has been conducted
  • Algorithms use straightforward implementations, not optimized variants
  • Memory allocations and data structures are basic
• Single‑Threaded Unpacking
  • V1 implements parallel processing only during packing. The unpacking phase runs sequentially, which significantly limits throughput in real‑world bidirectional use cases.

What the Numbers Actually Mean

Highly Compressible Text: 44.8 MB/s

Best‑case scenario where:

• Data compresses extremely well (99.57 % reduction)
• Parallel packing provides maximum benefit
• The system isn’t bottlenecked by I/O

Reality check: On optimized hardware with a production implementation, this could easily reach 500+ MB/s.

Low Compressibility Binary: 1.8 MB/s

Worst‑case for the two_pass mode where:

• Data doesn’t compress (100 % ratio maintained)
• System must process entire file for key derivation
• Python’s overhead becomes most apparent

Reality check: A compiled implementation could achieve 50–100+ MB/s for the same operation.

single_pass_firstN Mode: 17.5 MB/s

Shows architectural flexibility and performance improvement when key derivation doesn’t require full file processing.

Reality check: Still severely limited by Python. Expect 10–20× improvement in a production language.

The Real Performance Story

What We’re Actually Testing

• Architecture Viability – Does parallel processing + streaming + cryptography work together?
• Cryptographic Correctness – Does output achieve proper entropy (~8.0 bits/byte)?
• Implementation Completeness – Can it handle various file types and sizes?

What We’re NOT Testing

• Optimized Performance – Explicitly out of scope for a PoC
• Production Readiness – The code is foundational validation only
• Competitive Benchmarks – Comparing PoC Python to production tools is meaningless

Call for Community Testing

We need YOUR help to get real‑world performance data.
Since the published results come from a single budget laptop environment, they don’t represent the full picture. We encourage the community to:

Run Tests in Your Environment

git clone https://github.com/Qeltrix/test-poc-1.git
cd test-poc-1
python test_qeltrix.py

• Share your results along with hardware specifications.

Diverse Testing Scenarios

• Different operating systems (Linux, macOS, Windows)
• Various hardware configurations (workstations, servers, other laptops)
• Different system loads (dedicated testing vs. normal use)
• Various storage types (SSD, NVMe, HDD)

What We’ll Learn

• Performance variance across environments
• Identification of bottlenecks in various configurations
• Realistic baseline expectations for future optimization
• Data‑driven priorities for V2 and beyond

Looking Ahead: Production Implementation Potential

Expected Improvements

Conservative Estimate

A production‑ready Qeltrix implementation could realistically achieve:

• Highly compressible data: 500–2000 MB/s
• Mixed data: 200–800 MB/s
• Low compressibility data: 100–500 MB/s

Assumes modern hardware (8+ cores, NVMe SSD) and production‑quality code.

Why Performance Matters (Even for a PoC)

• Baseline Establishment – Knowing where we start to measure progress.
• Bottleneck Identification – Basic metrics reveal architectural constraints.
• Feasibility Validation – Proves the system can process real data at usable speeds.
• Design Validation – Mode comparisons (two_pass vs. single_pass_firstN) inform architectural decisions.

Conclusion: Set Your Expectations Appropriately

If you’re evaluating Qeltrix V1 PoC:

• Don’t compare these numbers to production tools.
• Don’t expect optimized performance from PoC code.
• Don’t assume Python performance represents the concept’s potential.
• Don’t judge the architecture by single‑environment testing.

Instead:

• Recognize this validates that the technical approach works.
• Appreciate the transparency in sharing limitations.
• Consider contributing testing data from your environment.
• Understand the massive performance headroom available.
• Focus on the architectural foundation being proven.

The V1 PoC achieves its goal: proving Qeltrix’s core concepts are technically viable. The performance numbers, while limited by Python and test‑environment constraints, demonstrate that even in the worst‑case implementation the system functions correctly and handles real‑world data.

The real performance story will be written when the community builds optimized implementations in production languages.

Get Involved

Help us gather real performance data:

• Test Repository: