EmbroideryPipeline 12-15x slower than the README's advertised budget #127

New issue

Closed

opened 2026-09-08 19:08:12 +00:00 by Mark · 0 comments

Mark commented

2026-09-08 19:08:12 +00:00

Owner

EmbroideryPipeline is 12-15x slower than the README's advertised budget

Repo: Mark/easystitch
Severity: Low — needs benchmark before sizing decisions
Found: 2026-09-08 full shakedown

Symptom

easystitch-service/README.md §Capacity & scaling:

Tail latency for POST /v1/digitize on a 1024x1024 PNG is ~600ms in Python + network;
budget for spikes to 5s.

Actual numbers from a single 2510x2562 PNG (~6x the pixel count of 1024^2):

Format	Time
DST	75.1s
PES	95.3s

Even adjusting for the 6x pixel ratio (which doesn't scale linearly), this is still ~2x slower
per pixel than advertised.

Why it matters

The SAAS pricing tiers (Small $49/50 designs, Pro $149/200 designs, Shop $399/unlimited) and
the MAX_QUEUE_DEPTH=8 sizing are sized off the 600ms budget. If real latency is 10-15x that,
queue saturation will happen 10-15x sooner under load.

Suggested next step

Profile a representative 1024x1024 PNG through EmbroideryPipeline.process(...) (not the
service wrapper) and capture per-stage timings. The bottleneck is most likely in raster
vectorization (felzenszwalb/saliency segmentation) since 2510x2562 takes much longer than
mixed-stitches SVG (a few KB).

Acceptance

Add a benchmark to tests/ that asserts processing_ms < 5000 on a 1024x1024 PNG fixture
Or update the README capacity section to reflect measured numbers with profile data cited

## EmbroideryPipeline is 12-15x slower than the README's advertised budget **Repo:** Mark/easystitch **Severity:** Low — needs benchmark before sizing decisions **Found:** 2026-09-08 full shakedown ### Symptom `easystitch-service/README.md` §Capacity & scaling: > Tail latency for POST /v1/digitize on a 1024x1024 PNG is ~600ms in Python + network; > budget for spikes to 5s. Actual numbers from a single 2510x2562 PNG (~6x the pixel count of 1024^2): | Format | Time | |---|---| | DST | 75.1s | | PES | 95.3s | Even adjusting for the 6x pixel ratio (which doesn't scale linearly), this is still ~2x slower per pixel than advertised. ### Why it matters The SAAS pricing tiers (Small $49/50 designs, Pro $149/200 designs, Shop $399/unlimited) and the `MAX_QUEUE_DEPTH=8` sizing are sized off the 600ms budget. If real latency is 10-15x that, queue saturation will happen 10-15x sooner under load. ### Suggested next step Profile a representative 1024x1024 PNG through `EmbroideryPipeline.process(...)` (not the service wrapper) and capture per-stage timings. The bottleneck is most likely in raster vectorization (felzenszwalb/saliency segmentation) since 2510x2562 takes much longer than mixed-stitches SVG (a few KB). ### Acceptance - Add a benchmark to tests/ that asserts `processing_ms < 5000` on a 1024x1024 PNG fixture - Or update the README capacity section to reflect measured numbers with profile data cited