DEV Community: TildAlice

EAL6+ vs EAL5+: Why Hardware Wallet Chip Certification Matters

TildAlice — Sat, 02 May 2026 00:02:47 +0000

Credit-card sized, four physical buttons, a small but crisp OLED display.

EAL6+ vs EAL5+: Why Hardware Wallet Chip Certification Matters

I spent three years trusting a Ledger Nano S before realizing I had no idea what "secure element" actually meant. The spec sheet said "CC EAL5+ certified" and I assumed that was good enough. Then I started researching hardware wallet attacks and discovered my assumptions were completely wrong.

What Common Criteria EAL Ratings Actually Mean

Common Criteria (CC) is an international security certification standard (ISO/IEC 15408) used to evaluate everything from smartcards to military hardware. The Evaluation Assurance Level (EAL) scale runs from EAL1 to EAL7, but most consumer hardware lives in the EAL4–EAL6 range.

Here's what each level requires:

EAL Level	What Gets Tested	Typical Use Case
EAL4	Methodically designed, tested, and reviewed	Payment cards, SIM cards
EAL5	Semi-formally designed and tested	Government ID cards, passport chips
EAL5+	EAL5 + specific attack resistance (AVA_VAN.5)	Most hardware wallets
EAL6	Semi-formally verified design and tested	Military communications, high-security banking

Continue reading the full article on TildAlice

uv vs pip vs Poetry: 50+ Package Install Speed Test

TildAlice — Fri, 01 May 2026 21:06:33 +0000

Installing 50 Packages Takes 2.5 Minutes with pip. uv Does It in 12 Seconds.

I cloned a Django project with 57 dependencies yesterday and ran pip install -r requirements.txt. Watched the terminal scroll. Made coffee. Came back. Still installing.

Then I tried uv pip install -r requirements.txt on the same lockfile. Twelve seconds.

This isn't a synthetic benchmark. This is a real mid-sized web app with Django, Celery, psycopg2, Pillow, and the usual suspects. The kind of project where pip install is the bottleneck in CI, local setup, and Docker builds.

But uv's speed comes with tradeoffs. Poetry gives you deterministic builds and dependency resolution that actually works. pip is everywhere and requires zero setup. So which one should you actually use?

I ran the same 57-package install across all three tools, measured cold cache, warm cache, and CI scenarios, and tracked exactly where each tool spends its time.

Photo by Willians Huerta on Pexels

The Test Setup: Real Project, Real Dependencies

Continue reading the full article on TildAlice

Prefix Tree vs Hash Map: 47% Slower Insert Reality

TildAlice — Fri, 01 May 2026 18:04:21 +0000

Hash maps dominate autocomplete implementations, but that's not the full story

Most production autocomplete systems use hash maps. They're simple, fast, and "good enough" for search boxes with a few thousand product names or city entries. But push them past 100k entries with shared prefixes — think domain names, file paths, or gene sequences — and you start seeing lag.

The classic computer science answer is "use a trie" (prefix tree). The reality? Tries are slower to build, use more memory, and only win in specific scenarios. I tested both on a 500k-word dictionary to see where the crossover happens.

The mental model: what each structure actually does

A hash map stores complete strings as keys. When you type "pyth", it doesn't know that "python" and "pythonic" share a prefix — it just checks if "pyth" exists as a key (it doesn't), then returns nothing. To support autocomplete, you have to scan ALL keys looking for matches. That's $O(n \cdot k)$ where $n$ is the dictionary size and $k$ is the average word length (for startswith() comparison).

A prefix tree (trie) stores strings character-by-character in a tree structure. Each node represents one character. The path from root to a node spells out a prefix. When you type "pyth", you walk down p→y→t→h in the tree (4 operations), then collect all words in that subtree. That's $O(p + m)$ where $p$ is the prefix length and $m$ is the number of matches.

Continue reading the full article on TildAlice

multiprocessing vs concurrent.futures: 2.1x Speed Gap

TildAlice — Fri, 01 May 2026 15:03:46 +0000

The API You Choose Changes Everything

Python's multiprocessing module and concurrent.futures.ProcessPoolExecutor both spawn processes to sidestep the GIL. They solve the same problem. But the overhead gap between them can hit 2.1x on small tasks.

I ran 10,000 CPU-bound jobs (prime factorization up to 10^6) on both APIs, Python 3.11, M1 MacBook. ProcessPoolExecutor finished in 4.2 seconds. Raw multiprocessing.Pool took 8.9 seconds. Same work, same process count, wildly different runtimes.

The culprit? Task submission overhead and result serialization. concurrent.futures batches tasks more aggressively and amortizes pickle costs. multiprocessing.Pool.map() incurs per-task IPC overhead that compounds at scale.

This post benchmarks both APIs on three real workloads: embarrassingly parallel number crunching, I/O-mixed tasks, and large result sets. You'll see where ProcessPoolExecutor wins, where raw multiprocessing fights back, and the one scenario where neither matters.

Photo by Christina Morillo on Pexels

Continue reading the full article on TildAlice

Adjacency List vs Matrix: 47% Faster DFS in Interview Code

TildAlice — Thu, 30 Apr 2026 21:04:57 +0000

Why Your Graph Choice Tanks Interview Performance

Most candidates freeze when asked "adjacency list or matrix?" during graph problems. They mumble something about sparse vs dense graphs, then pick one arbitrarily and hope it works. But here's what actually matters: the wrong choice doesn't just waste memory — it kills your runtime on test cases that matter.

I ran the same DFS traversal on a 1000-node graph using both representations. Adjacency list: 0.8ms. Adjacency matrix: 1.5ms. That's 47% slower for identical logic.

And it gets worse with certain graph patterns.

The Memory Trap Nobody Mentions

Everyone knows the space complexity formulas. Adjacency list: $O(V + E)$ where $V$ is vertices and $E$ is edges. Adjacency matrix: $O(V^2)$ regardless of edge count.

But interview problems don't care about your Big-O theory — they care about whether your code passes the hidden test case with 10,000 nodes and 15,000 edges (a fairly sparse social network graph). That adjacency matrix allocates 100 million boolean values. Python booleans are 1 byte each. You just consumed 95MB for a graph that should take under 1MB.

LeetCode's memory limit? Often 256MB. You're already using 37% of your budget before storing anything else.

Continue reading the full article on TildAlice

SAM vs FastSAM vs SAM 2: Inference Speed Benchmark

TildAlice — Thu, 30 Apr 2026 18:05:14 +0000

FastSAM is 15x faster than SAM on my RTX 3090, but it misses 22% of fine details

I spent the weekend running 500 images through SAM, SAM 2, and FastSAM to settle the speed-vs-quality debate once and for all. The headline number everyone quotes—"FastSAM is 50x faster!"—turns out to be misleading. On real-world images with mixed object sizes, the gap shrinks dramatically, and the quality trade-off is harder than the papers suggest.

Here's what actually happened when I benchmarked all three models on identical hardware with consistent preprocessing. The results surprised me, especially around memory usage.

Photo by RDNE Stock project on Pexels

The models: architecture differences that explain the speed gap

SAM (Segment Anything Model, Kirillov et al., 2023) uses a massive ViT-H image encoder with 632M parameters. The encoder runs once per image, producing a 256×64×64 embedding. Then for each prompt (point, box, or mask), a lightweight decoder generates the segmentation in ~50ms. Total first-frame time? Around 3-4 seconds on GPU.

Continue reading the full article on TildAlice

Linear vs Binary Search: 1M Element Speed Test Results

TildAlice — Thu, 30 Apr 2026 15:04:16 +0000

The 400x Speed Gap Nobody Talks About

Linear search gets demolished by binary search on sorted data. Everyone knows that in theory. But here's what surprised me: on a 1 million element array, binary search wasn't just faster — it was 418 times faster in the worst case. And in the average case? The gap widened to over 600x.

Most coding interview prep skips the actual performance measurement. They show you the $O(n)$ vs $O(\log n)$ notation and move on. But when you're sitting in an interview and the interviewer asks "which algorithm would you choose for this scenario," the answer depends on details that Big-O notation doesn't capture: dataset size, whether the data is sorted, memory constraints, and how often you're searching.

I ran both algorithms on the same 1 million element dataset with different scenarios: best case, worst case, average case, and repeated searches. The results show exactly when linear search is acceptable (hint: almost never on large datasets) and when you'd be crazy not to use binary search.

How Each Algorithm Works

Linear search is dead simple: start at index 0, compare each element to your target, return when you find it (or reach the end). The search time grows linearly with array size. If you're looking for the last element in a million-item list, you check all million items.

Continue reading the full article on TildAlice

Chain-of-Thought vs Few-Shot: 34% Accuracy Gap on GSM8K

TildAlice — Wed, 29 Apr 2026 21:04:50 +0000

Chain-of-Thought Beats Few-Shot by 34% on Grade School Math

GSM8K is a dataset of 8,500 grade school math word problems that trip up even large language models. When I tested GPT-3.5-turbo with standard few-shot prompting, accuracy hovered around 23%. Switching to chain-of-thought (CoT) prompting — where the model writes out intermediate reasoning steps — jumped accuracy to 57%.

That's a 34 percentage point gap from the same model, same API call, just a different prompt structure.

The gap isn't magic. CoT forces the model to decompose multi-step reasoning into explicit steps, which prevents the arithmetic and logical errors that plague direct answer generation. But it comes with a cost: 3.2x more tokens per response, which translates directly to API spend and latency.

Photo by cottonbro studio on Pexels

What GSM8K Actually Tests

GSM8K problems look deceptively simple:

"Natalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May?"

Continue reading the full article on TildAlice

Pandas Join Performance: merge() vs concat() vs join()

TildAlice — Wed, 29 Apr 2026 18:04:24 +0000

merge() Beats concat() by 12x on Indexed Lookups

I benchmarked all three Pandas join methods on a 500K-row customer dataset with a 200K-row transaction table. merge() completed in 0.18s, join() in 0.21s, and concat() took 2.4s. That's not a typo — concatenation with axis=1 was over 12 times slower than a hash join.

Most tutorials treat these as interchangeable "ways to combine DataFrames." They're not. Each method optimizes for a completely different use case, and picking the wrong one tanks performance or silently produces incorrect results.

Here's what actually matters: merge() is a relational database join (hash-based, column matching), join() is index-aligned merging (defaults to left join on index), and concat() is axis-wise stacking (intended for appending rows or columns without matching logic). The syntax overlap fools people into thinking they're equivalent.

Photo by Joanie xie on Pexels

The Benchmark Setup

Continue reading the full article on TildAlice

Backtest.py to Vectorbt: 3x Faster Parallel Strategies

TildAlice — Wed, 29 Apr 2026 15:05:57 +0000

Why Backtest.py's Loop-Based Design Kills Multi-Strategy Testing

Running 50 variations of a moving average crossover strategy in Backtest.py takes about 12 minutes on my M1 MacBook. The same test in vectorbt finishes in under 4 minutes.

The gap isn't about code quality — it's architectural. Backtest.py runs each strategy sequentially in a Python loop, recalculating indicators and event handling for every parameter combination. Vectorbt precomputes everything as NumPy arrays and broadcasts operations across all parameter sets simultaneously. When you're testing hundreds of hyperparameter combinations (different MA windows, stop-loss levels, position sizing rules), that difference compounds fast.

I migrated a pairs trading system from Backtest.py to vectorbt last month. The migration itself took maybe 3 hours, but the real payoff came when I started running parameter sweeps — what used to be overnight grid searches now finish during lunch.

This isn't a hit piece on Backtest.py. It's a fantastic library for beginners: clean API, great documentation, easy to reason about. But if you're moving from "test one strategy" to "test 100 variations in parallel," you'll hit its performance ceiling hard.

Continue reading the full article on TildAlice

GraphSAGE vs GAT: Reddit/PPI Inductive Learning 95% F1

TildAlice — Tue, 28 Apr 2026 21:06:28 +0000

The 95% F1 Barrier on Reddit That Broke GCN

Graph Convolutional Networks hit a wall. Not because they weren't accurate—Kipf and Welling's GCN (ICLR 2017) dominated transductive tasks—but because they couldn't handle nodes that didn't exist during training. Every time Reddit added a new user or PPI discovered a new protein interaction, the entire model needed retraining. You can read the full GraphSAGE paper here and the GAT paper here.

GraphSAGE (Hamilton et al., NeurIPS 2017) cracked this by learning aggregation functions instead of fixed embeddings. GAT (Veličković et al., ICLR 2018) took a different route: attention-weighted neighbors. Both papers claimed inductive superiority—but which actually delivers when you're staring at 232,965 Reddit posts or 56,944 PPI proteins?

I ran both implementations on identical hardware, and the results weren't what I expected.

Photo by Google DeepMind on Pexels

GraphSAGE: Sampling Neighbors to Scale

Continue reading the full article on TildAlice

tmux Scroll vs Terminal: 10K Line Benchmark Results

TildAlice — Tue, 28 Apr 2026 15:03:35 +0000

The Myth of tmux Scroll Overhead

A colleague insisted tmux was "destroying his scroll performance" when tailing logs. He'd switched to running everything bare in iTerm2, convinced the multiplexer layer was the bottleneck. But when I tested scrolling through 10,000 lines of dense output, the results flipped his assumption.

tmux's scroll-back buffer isn't the problem most people think it is. The terminal emulator's rendering engine matters far more than the multiplexer sitting between your shell and the display. In fact, across four different terminal emulators running identical tmux configurations, I measured a 3.8x difference in scroll responsiveness — while tmux vs. no-tmux on the same emulator showed only a 1.2x gap.

The real performance story is about GPU acceleration, text shaping engines, and how your terminal handles rapid frame invalidation. Not the tmux layer.

Photo by Lukas Blazek on Pexels

Test Setup: Controlled Chaos

Continue reading the full article on TildAlice