Performance — SCORPIOX CODE

Overview

scorpiox code is written in C11 — a language with no runtime, no garbage collector, and direct control over every byte of memory. Every one of the 56 executables is statically linked: a single binary with zero dynamic library dependencies, zero interpreter startup cost, and deterministic memory behavior from the first instruction.

The build system (CMake 3.16+) compiles shared static libraries — sxutil, sxnet, sxui, sxterm — and each tool links only the libraries it needs. The result: small binaries, fast compilation, and no wasted code.

Build Configuration

C11 standard · -O2 release optimization · -Wall -Wextra warnings · Static linking via SX_STATIC_LINK=ON · Platform conditionals eliminate dead code per target (Linux, macOS, Windows, ARM64, WASM).

Memory Management

Every memory allocation strategy in scorpiox code is chosen to avoid fragmentation, bound worst-case usage, and eliminate runtime overhead. No garbage collector. No reference counting. Just fixed buffers, ring buffers, and careful lifecycle management.

Static Allocation (WASM)

Terminal rendering on WASM uses static SxCell arrays — zero malloc at init, no fragmentation.

                        static SxCell front[256×64]
static SxCell back[256×64]
static char out_buf[64KB]
                    

Fixed-Size Config Structs

Config entries use fixed char[64] keys and char[512] values — zero heap allocation per entry.

                        SX_CONFIG_MAX_KEY  = 64
SX_CONFIG_MAX_VAL  = 512
                    

Rolling Ring Buffer

Background tasks use a 64KB rolling buffer — fixed memory ceiling, old data evicted automatically.

                        SX_BGTASK_OUTPUT_MAX = 65536
max 8 tasks = 512KB total
                    

Doubling Growth Buffer

Request builder uses 2x growth from 64KB initial — amortized O(1) append for API bodies.

                        DEFAULT_CAPACITY  = 65536
GROWTH_FACTOR    = 2
                    

Lock-Free Atomic Counters

C11 stdatomic tracks every fork, popen, pipe — zero mutex contention for resource accounting.

                        8 atomic counters
atomic_fetch_add + CAS peak
                    

Capped Script Output

Tool execution output capped at fixed buffer — prevents runaway tool output from consuming unbounded memory.

g_script_output[4096]

Process Leak Detection

Atomic counters track every fork(), popen(), and pipe() open/close. At shutdown, sx_procmon_summary() reports any leaked resources. This catches resource leaks at the C level — something garbage-collected languages can't do.

I/O & Rendering

Double-Buffered Cell Diff Rendering

The TUI uses a front/back cell buffer. On each frame, only changed cells emit ANSI escape sequences. Output is batched through a large write buffer and flushed once at the end.

1MB

Native Output Buffer

Single write buffer for batched terminal output. WASM uses 64KB.

1024×512

Max Grid (Native)

Maximum terminal grid size. WASM limited to 256×64 cells.

Rendering optimizations:

cell_eq() comparison skips unchanged cells — no redundant escape codes
Batched attribute/color state — escape codes emitted only on change
Cursor position tracking — skip CSI movement for sequential writes
Cursor hidden during update, single flush at frame end

JSON Parsing: yyjson

All API request/response parsing uses yyjson — the fastest C JSON parser available. SIMD-optimized, in-situ parsing, immutable + mutable document APIs.

~3 GB/s

Parse Speed

On modern CPUs with SIMD acceleration.

~1.5 GB/s

Serialize Speed

Fast output generation for API payloads.

YYJSON_WRITE_ALLOW_INVALID_UNICODE — prevents crashes from bad UTF-8 in tool output
Dot-path accessor (walk_path) for nested JSON queries
Raw JSON fragment injection (sx_yy_obj_add_raw) — parse once, zero-copy insert

I/O Multiplexing

Synchronous I/O with select() multiplexing for terminal input, email server clients (SMTP + IMAP + Submission), and DNS (UDP + TCP). The KVM runner uses poll() for non-blocking stdin.

Binary Architecture

56 executables are built from 7 shared static libraries. Each tool links only what it needs — the linker strips unused symbols, keeping binaries small.

Library	Source Files	Purpose
sxutil	22 files	Core utilities — config, log, exec, JSON, procmon, conversation
sxnet	16 files	Network layer — HTTP, providers, agent, MCP, FRP, host
sxui	7 files	TUI widgets — display, input, file explorer, bashterm
sxterm	1 file	Terminal abstraction — double-buffered cell rendering
sxbridge	1 file	Bridge module for IPC
yyjson	1 file	High-performance JSON parser (vendored)
mbedtls	60 files	TLS 1.2/1.3 — embedded crypto, no OpenSSL dependency

Smallest Binary

scorpiox-config — single-file config tool, minimal library deps. Links only sxutil.

Largest Binary

sx — main TUI. Links sxutil + sxnet + sxui + sxterm + mbedtls + yyjson + curl.

Static Linking

All binaries use -static linking (musl/glibc + libcurl + mbedTLS + yyjson). Zero dynamic linker overhead, no .so resolution at startup, works on any matching-architecture Linux without library compatibility issues.

Networking & Protocols

HTTP Client

Native: libcurl (static). WASM: Emscripten Fetch API. Unified sx_http.h interface — build selects implementation at compile time.

Streaming SSE for token-by-token display
Cancel callback for user interruption
Growing response buffer (2x doubling)

FRP Tunnel (yamux)

Multiple logical streams over single TCP+TLS connection. 12-byte header per frame, connection pooling, AES-128-CFB encrypted control.

                        YAMUX_MAX_STREAMS     = 64
FRP_MAX_WORK_CONNS    = 32
YAMUX_INITIAL_WINDOW  = 256KB
                    

Embedded TLS

mbedTLS vendored — TLS 1.2 + 1.3 support. No OpenSSL dependency. Smaller binary, faster compilation, predictable memory.

Zero-Copy File Transfer

sendfile() kernel-space copy with streaming xxHash64 verification. Fallback path uses large-buffer read/send with SO_SNDBUF tuning.

Protocol Implementations

DNS Server

Full DNS: UDP+TCP, split-horizon, upstream forwarding with response caching. A records, zone management CLI, TC flag for TCP retry.

Email Server

SMTP + Submission + IMAP with STARTTLS, DKIM signing, maildir storage.

                        MAX_CLIENTS = 64 (per protocol)
BUFFER      = 64KB per client
MAX_MSG     = 25MB
                    

MCP Integration

Model Context Protocol — discovers tools from MCP servers, namespaces as mcp__<server>__<tool>.

SX_MCP_MAX_TOOLS = 512

Terminal Multiplexer

tmux-compatible: Unix domain socket IPC, VT100/ANSI emulator per pane.

                        MAX_SESSIONS = 32
MAX_PANES    = 64
VT_MAX_COLS  = 512
                    

Compile-Time Optimizations

Platform conditionals (SX_LINUX / SX_MACOS / SX_WINDOWS / __EMSCRIPTEN__) eliminate dead code per platform at compile time. Each target includes only the code paths it needs.

                Conditional Compilation
                // WASM excludes:
pthread, fork, pty, procmon, bgtask, cache_keepalive

// Windows uses:
CriticalSection, _popen, CreateProcess

// Linux uses:
epoll-capable select, pty, unshare, KVM

// macOS:
mostly-static (Wl,-search_paths_first)
            

Startup Optimizations

All subsystems use init-once pattern (atomic flag or bool guard) — safe to call multiple times with zero overhead on subsequent calls
System prompt generated once per session, cached in static pointer — invalidated only on tool state change
Cache keep-alive timer fires at 270s (4:30) intervals — max 12 pings per session (~1hr coverage) to keep Claude prompt cache warm

Error Recovery

                Exponential Backoff
                // Transient HTTP errors: 429, 500, 502, 503, 529
SX_RETRY_MAX_ATTEMPTS  = 10
initial_delay          = 1000ms
max_delay              = 60000ms
backoff_factor         = 2
            

Benchmarks vs. Alternatives

Comparisons based on typical resource usage for AI coding assistants built with each technology stack:

vs. Node.js 100× less memory

~2-5MB RSS vs 200-500MB. 10× faster startup (<5ms vs 500ms+). No garbage collection pauses. Single static binary vs node_modules tree.

vs. Python 50× less memory

Instant startup vs interpreter boot. Compiled to native machine code. No pip dependencies or virtualenvs.

vs. Go 10× smaller binary

Static C vs Go runtime. Similar execution speed. No garbage collector. Finer-grained memory control with fixed buffers and rolling allocators.

vs. Rust Comparable performance

Memory safety via careful C. Faster compilation. Simpler FFI. Broader embedded/WASM toolchain compatibility.

vs. Electron 1000× less memory

~2MB vs 200MB+. Instant startup vs Chromium boot. No bundled browser engine. 56 focused tools vs monolithic app.

Cross-Platform Targets

Five platform targets, each with platform-specific adaptations:

Linux x86_64

Primary target. Full feature set: epoll, pty, unshare containers, KVM.

Linux ARM64

Same features as x86_64. Cross-compiled via CMake toolchain files.

macOS

Mostly-static linking. -Wl,-search_paths_first for library resolution.

Windows

CriticalSection for threading, _popen/CreateProcess for execution, native console APIs.

WebAssembly (Emscripten)

Static cell buffers (no malloc). 64KB output buffer. Emscripten Fetch API replaces libcurl. JS bridges for xterm.js terminal. No pthreads, no fork, no pty — single-threaded cooperative execution.