sigmod-experiments
GitHub指导SIGMOD论文实验设计，涵盖实验配置披露、工作负载真实性分级、基线公平性协议及多维性能曲线分析。确保评估能经受同行评审质疑，通过消融实验隔离机制贡献，避免玩具工作负载和配置偏差问题。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sigmod-experiments -g -y
SKILL.md
Frontmatter
{
"name": "sigmod-experiments",
"description": "Use when designing or auditing the evaluation of a SIGMOD paper, covering workload realism and standard benchmark usage, baseline tuning fairness, scalability and tail-latency methodology, ablations that isolate the mechanism, and the setup disclosure a data-systems PC demands before trusting any speedup."
}
SIGMOD Experiments
The evaluation section decides most SIGMOD verdicts. A data-systems PC does not ask whether your system is fast; it asks whether the experiments would convince the person who built the baseline you beat. Design the evaluation to survive that specific reader.
The setup table comes first
Before any result, the paper owes a complete experimental contract: hardware (CPU, memory, storage class, network), software versions, datasets with scale, workloads with skew and mix parameters, baseline versions and tuning provenance, repetition counts, and warm-up policy. At SIGMOD this is not appendix material — reviewers skim to it before reading the design.
Workload realism ladder
| Rung | Example | Evidentiary weight |
|---|---|---|
| Microbenchmark | Single-operator stress loop | Explains mechanisms; proves little alone |
| Standard benchmark | TPC-style, YCSB-style suites at stated scale | Comparable across papers; known blind spots |
| Trace-derived | Public or characterized production traces | High, if provenance is disclosed |
| End-to-end application | Full query mix on realistic schema | Highest, rarely achieved |
A SIGMOD-strong evaluation climbs the ladder: microbenchmarks to expose the mechanism, a standard suite for comparability, and at least one workload that argues real deployments look like this. An evaluation living entirely on rung one gets the "toy workloads" objection regardless of speedups.
Baseline fairness protocol
The evaluation's credibility ceiling is the weakest baseline treatment:
- Use current versions, compiled with the same optimization effort as your system, configured per their documentation or authors.
- Enable the competitor's relevant features — comparing your tuned build against a default-config rival is the field's best-known foul.
- Where a baseline's own paper reports numbers on similar hardware, reconcile: if you measure it slower than its authors did, say why.
- Include the boring-but-strong baseline (a mature engine, a well-indexed Postgres, a hand-tuned flat scan); beating only research prototypes invites the question you least want.
Curves, not points
- Scalability: sweep threads/cores/nodes and show the shape; a single-point "64-core" result hides the knee reviewers care about.
- Data size: sweep scale factors; crossover points against baselines are more informative than any fixed-size win.
- Skew and contention: sweep the skew parameter; uniform-only evaluation of a concurrency or caching contribution is near-disqualifying.
- Latency: percentiles across the sweep, since p99 behavior under load is frequently where the contribution actually lives (or dies).
Ablations that isolate the mechanism
If the system adds three techniques, the evaluation must attribute the gain: a cumulative build-up (base, +A, +A+B, full) or leave-one-out grid. The review question being preempted is "is the win just the rewrite?" — so where feasible, include the strongest possible your-system-minus-the-idea configuration as its own baseline.
Run hygiene
For every plotted point:
runs >= 5 (or stated justification), report median + spread
cold vs. warm state declared; caches handled identically across systems
same measurement harness for all systems; harness in the artifact
seeds pinned for generated data and workload shuffles
outlier policy stated before running, not after seeing results
Numbers that move between the submitted and revised versions without an explained cause are a specific, remembered failure mode in multi-round review — hygiene at first submission protects the revision.
Matching metrics to contribution type
- Storage/index structures: throughput plus space amplification plus build/maintenance cost — one without the others invites the "what did it cost" question.
- Transaction/concurrency work: abort rates and tail latency under contention, not just committed-throughput peaks.
- Query processing: per-query breakdowns alongside suite totals; a suite geomean can hide one catastrophic regression reviewers will find.
- Distributed systems: report behavior during failures and rebalancing, not only steady state.
- ML-for-systems: include the training/adaptation cost and the stale-model regime; the "what happens when the workload shifts" question is now standard at this venue.
Negative-result honesty
Show where the system loses: the workload regime where the incumbent wins, the overhead paid on the unfavorable mix. A measured, explained loss buys more trust with this PC than any additional win, and it pre-writes the limitations paragraph reviewers will otherwise draft as an objection.
Output format
[Setup contract] complete / missing items listed
[Ladder position] rungs covered; realism gap
[Baseline audit] versions, tuning, features, reconciliation
[Curve coverage] scalability / size / skew / percentile sweeps present
[Attribution] ablation design isolates each claimed technique yes/no
[Loss map] regimes where the system loses, disclosed or hidden
[Decisive missing run] the one experiment to add before the round
Version History
- 9f86f09 Current 2026-07-19 17:37
