turbo-picard documentation

turbo-picard is for teams already using Picard that want the strongest practical replacement: faster execution, lower memory pressure, and a cleaner adoption path with almost no pipeline rewiring.

It keeps the command shape people already know:

picard MarkDuplicates I=input.bam O=marked.bam M=metrics.txt

turbo-picard keeps the full Picard 3.4.0 interface. Accelerated commands run natively in Rust, and every other command delegates to upstream Picard when it is installed or auto-discovered. The rollout model is deliberately incremental: replace one Picard command at a time, compare outputs with your pipeline, then expand once the first boundary is proven.

The current saved benchmark suite reports 32/32 parity-checked commands, a 8.01x floor speedup, 26.67x geometric mean speedup, and 75.77x top speedup. The checked MarkDuplicates performance run in the repository also cuts median RSS from about 1.2 GB in Picard 3.4.0 to about 8.7 MB in turbo-picard. That is why the project is positioned as both faster and easier to fan out across real pipeline workloads, even though the intended workflow is still careful switching rather than blind replacement.

Start here

New user

Install from PyPI, check the two entrypoints, and run a first Picard-style command.

Quickstart

Is this for you?

Decide quickly whether this is worth evaluating in your workflow at all.

Is this for you?

Pipeline owner

Follow the shortest path from first interest to trial, review, and team rollout.

Evaluation playbook

Use cases

See the workflow situations where this package is most likely to help.

Use cases

Command lookup

See which Picard commands are native, partly native, or fallback-only.

Command coverage

Picard vs turbo-picard

See what stays the same, what changes, and when to stay with Picard.

Picard vs turbo-picard

turbo-picard vs riker

Compare drop-in Picard acceleration against riker’s QC-only redesign.

turbo-picard vs riker

FAQ

Get direct answers to the common evaluation and rollout questions.

FAQ

First command

Pick the best first Picard step to trial instead of guessing.

Choose your first command

Packaging

Understand PyPI, the optional picard shim, citation boundaries, and the Bioconda release path.

Packaging

User Guide

• Quickstart
  • Install with pip
  • Install from source
  • Run a familiar command
  • Check the runtime
  • Good first commands
  • CRAM inputs and outputs
  • Before changing a workflow
• Is this for you?
  • Good fit
  • Probably not a fit yet
  • What a sensible first evaluation looks like
  • Where to go next
• Choose your first command
  • Start with MarkDuplicates
  • Start with SortSam
  • Start with SamToFastq
  • Start with BuildBamIndex
  • What to avoid as the first trial
  • Next step
• Evaluation playbook
  • 1. Decide whether a trial is worth doing
  • 2. Pick the first command
  • 3. Pick the workflow shape
  • 4. Run the smallest honest trial
  • What this is not
• Use cases
  • WDL / Cromwell preprocessing pipelines
  • Nextflow / nf-core modules
  • Snakemake and shell pipelines
  • Platform teams and shared workflow environments
  • When none of these are your situation
• Picard vs turbo-picard
  • Short version
  • What stays familiar
  • What changes
  • What you get in return
  • What you still need to do
  • How to choose
  • Where to go next
• turbo-picard vs riker
  • Short answer
  • What overlaps
  • Where turbo-picard is ahead today
  • Speed profile today
  • Where riker is ahead today
  • Deployment and operational friction
  • How to benchmark them fairly
  • Practical rollout guidance
• FAQ
  • Is this trying to replace all of Picard?
  • How do we know where to start?
  • What if our workflow still needs upstream Picard?
  • What if the benchmark numbers do not match our workflow?
  • What if we depend on exact Picard-rendered plots?
  • What is the smallest honest evaluation?
  • When should we stay with upstream Picard for now?
• Trying turbo-picard in a pipeline
  • Workflow shapes
  • Check a representative file
  • GATK-style preprocessing
• What Parity Means
  • What Gets Compared
  • CRAM preprocessing parity
  • What Parity Does Not Prove
  • How To Use The Evidence
• Fallback behavior
  • Auto-discovery
  • Explicit override
  • What delegates
  • What does not delegate
  • Avoid fallback loops
• Command coverage
  • Common command examples
  • Metrics and repair examples
  • VCF and interval examples
  • Machine-readable coverage
• Benchmarks
  • Run the suite
  • Read benchmark claims carefully
  • Genome-scale evidence
  • Large-input speed evidence
  • Real-data parity evidence
• Performance Notes
  • Threading
  • Metrics accumulation
  • Profiling benchmark runs
  • GPU acceleration
  • What to benchmark
• Citation
• Packaging
  • Main package
  • Compatibility shim package
  • PyPI
  • Container image
  • Conda-style deployment
  • Bioconda release path
• Troubleshooting
  • Unsupported command
  • Fallback appears to recurse
  • Output differs from Picard
  • Index or md5 files are missing
  • Bioconda recipe still uses source.path

Project

• Development
  • Useful checks
  • Documentation rules of thumb