# data.table vs dplyr for Large Genomic Data in R The core difference is this: data.table modifies tables in place with a compact, index-based syntax built for speed and memory efficiency, while dplyr provides a readable, copy-based grammar built for clarity and integration with the rest of the tidyverse. The rule of thumb for genomic work: if a single table runs past a few gigabytes, if you filter and join tables with hundreds of millions of rows, or if your workstation struggles to hold the data plus a working copy in RAM, use data.table. If your tables fit comfortably in memory, if reviewers and collaborators need to read your code, and if you work inside Bioconductor and tidyverse packages, use dplyr. This article covers both packages on their own terms, compares them on the criteria that actually decide the choice in genomics projects, walks through worked scenarios such as GWAS quality control and biobank-scale phenotype joins, and lists the mistakes that burn the most time in real pipelines. ## Why Table Size Decides Tooling in Genomics R for bioinformatics lives or dies on how well it moves rectangular tables. A variant-by-sample genotype matrix, a GWAS summary statistics file, a peptide intensity table, or a metadata sheet keyed by sample identifier are all rectangular tables, and most of a bioinformatician's day is spent filtering, joining, reshaping, and summarizing them. The pressure comes from scale. Genome-wide association studies routinely involve millions of genetic markers across tens or hundreds of thousands of samples, and biobank projects collect data at a scale that demands highly efficient and scalable processing software [1]. Population-scale pedigree analyses in R, such as those implemented in the LT-FGRS package, face the same constraint and must keep computational cost manageable across Nordic-registry-sized datasets [2]. The authors of BESSiE, a tool for genomic BLUP and Bayesian analysis of marker data, noted the underlying problem plainly: script-based environments like R may struggle to handle large-scale genomic data unless the software exploits model properties that save computing time and memory [3]. Both data.table and dplyr attack this problem, but from different directions. data.table saves time by avoiding unnecessary copies of your data. dplyr saves time by making your intentions unambiguous, which reduces bugs and lets the same grammar run against databases and other backends. Neither approach is universally correct, which is why the choice deserves an explicit decision rather than habit. ## Side-by-Side Comparison The table below is the core of the comparison. Each row is a criterion that decides real project choices, and the details behind each row follow in later sections. | Criterion | data.table | dplyr | |--|--|--| | File import | `fread()` reads delimited files fast, with `nThread` and `select` options | `readr::read_csv()` is fast and strict about types, generally slower than `fread()` | | Modification model | Modifies in place by reference (`:=`), no full-table copy | Copy-on-modify semantics, each mutation can create copies | | Filtering and selection | `DT[x > 0 & chr == "1"]`, columns by name or position | `filter()`, `select()`, verbose and pipe-friendly | | Grouped operations | `DT[, .(mean = mean(y)), by = grp]`, very fast with keys | `group_by()` then `summarize()`, comparable logic, more overhead on huge data | | Joins | `X[Y, on = "id"]` keyed joins, extremely fast for large tables | `left_join()`, `inner_join()` and friends, explicit `by` argument, easy to read | | Ordering and indexing | `setkey()`, `setorder()` create physical sort orders that speed later joins | `arrange()` sorts on demand, no persistent index | | Memory behavior | Low overhead, in-place updates avoid doubling RAM use | Copies during mutations can peak memory on wide or long tables | | Syntax style | Terse, brackets, unusual at first | Verb-based, reads like English sentences | | Ecosystem | Focused package, also underlies many CRAN packages | Center of the tidyverse, integrates with ggplot2, tidyr, dbplyr, arrow | | Bioconductor integration | Common in high-performance genomics packages internally | Common in user-facing workflows and reporting packages | | Beyond-RAM strategy | `fread()` with `select`, chunked processing, keyed rollups | `dbplyr` for SQL databases, `arrow` for Parquet files | | Parallelism | `nThread` for import, built-in parallel grouped operations | Parallelism via companion packages such as `furrr` or `multidplyr` | | Best fit | Tables over ~1 GB, hot loops, frequent joins on millions of rows | Tables that fit in RAM, exploratory analysis, teaching, shared pipelines | ## data.table on Its Own Terms data.table is a single R package built around one object class, the data.table, which extends the base data.frame. Its design goal is explicitly to reduce compute time and memory use, and it achieves that through three mechanisms: a fast C-level reader, in-place modification by reference, and keyed indexing. ### Fast Import with fread The `fread()` function reads delimited text files and autodetects the separator, quoting rules, and column types. For a GWAS summary statistics file with columns for chromosome, base pair position, reference allele, effect size, and p-value, import looks like this: ```r library(data.table) gwas <- fread("gwas_chr1.txt", nThread = 8) ``` Two options matter most for large genomic files. `nThread` controls how many CPU threads fread uses during reading, and on multi-core machines this alone often cuts import time dramatically. `select` reads only the columns you name, which is the single most effective memory saving available when a file has more columns than you need: ```r gwas <- fread("gwas_chr1.txt", select = c("CHR", "BP", "SNP", "A1", "BETA", "P"), nThread = 8) ``` Reading six of thirty columns cuts both the disk parse time and the resident memory roughly in proportion. Package authors building GWAS tooling in R rely on exactly these kinds of optimizations. GWAtoolbox, an R package for quality control of GWAS meta-analysis files, was designed around the goal of performing QC on large numbers of files in minutes rather than hours [4], and PRSice-2 demonstrates the payoff at the application layer: it was written specifically to be dramatically faster and more memory-efficient than its predecessor for biobank-scale polygenic risk score analysis [1]. ### In-Place Modification with := The defining feature of data.table is modification by reference. In base R and in dplyr, assigning a new column typically copies the whole table or large parts of it. data.table's `:=` operator updates the table in place, so the memory footprint stays flat: ```r gwas[, p_bonf := p.adjust(P, method = "bonf")] ``` Here `p_bonf` is added to `gwas` without creating a second copy of a multi-gigabyte table. This behavior matters most when you transform columns iteratively, for example converting base pair positions to genome build coordinates, recoding alleles, or computing moving statistics along a chromosome. ### Keyed Indexing and Joins `setkey()` physically reorders the table by the key columns and builds an index. After keying, filters on the key columns use binary search rather than a full scan, and joins between keyed tables run at speeds that make repeated merging of large variant tables practical: ```r setkey(pheno, sample_id) setkey(geno_meta, sample_id) merged <- pheno[geno_meta] ``` This keyed-join pattern is the workhorse of cohort assembly, where a phenotype table and a genotype or variant annotation table must be aligned by sample or variant identifier. When the join is performed many times, for example once per chromosome or once per trait, the index cost is paid once and every subsequent join benefits. ### Grouped Summaries by Chromosome or Gene The bracket syntax `[i, j, by]` reads as "filter with i, compute j, group by by." Summarizing association results per chromosome is a one-liner: ```r gwas[, .(n_variants = .N, min_p = min(P)), by = CHR] ``` The same syntax handles rolling operations along ordered positions, which is useful for genomic interval work such as counting variants in sliding windows. ## dplyr on Its Own Terms dplyr is the data manipulation grammar of the tidyverse, a collection of R packages sharing a common design philosophy. Its verbs, including `filter()`, `select()`, `mutate()`, `summarize()`, `group_by()`, and `arrange()`, map directly onto the operations bioinformaticians describe in plain language. ### The Verb Grammar The same GWAS summarization from above reads as follows: ```r library(dplyr) gwas %>% group_by(CHR) %>% summarize(n_variants = n(), min_p = min(P)) %>% ungroup() ``` The pipe (`%>%` or the native `|>`) chains operations left to right. For someone reading the code six months later, or a collaborator reviewing a methods section, this reads as a sentence: group by chromosome, count variants, take the minimum p-value, ungroup. That readability is a genuine engineering property, not a cosmetic one, because most cost in large projects comes from misunderstood code rather than slow code. ### Copy-on-Modify and What It Costs R's normal behavior is copy-on-modify: when you change a value, R copies the affected object. dplyr follows this model. For a table of a few million rows this is irrelevant, because modern R shares column memory until modification and copies are cheap. For a table with hundreds of millions of rows and dozens of mutation steps, the copies accumulate and the peak memory use can approach several times the size of the input. This is the single largest practical difference between the two packages, and it is why the same dplyr script that runs in seconds on a 2 GB expression matrix can grind or crash on a 40 GB variant-level table. ### Backend Flexibility with dbplyr and arrow dplyr's greatest architectural strength is that the same verbs can run against data stored outside R memory. With `dbplyr`, a dplyr pipeline is translated into SQL and executed on a PostgreSQL or DuckDB database, so operations run on data far larger than RAM. With the `arrow` package, the same verbs run against Parquet files with lazy evaluation. For genomics groups whose raw results live in databases, this means a dplyr script written for an in-memory table often works against the database version with a one-line change, replacing `tbl()` for the data frame with a database table reference. ### Fit with the Bioconductor Ecosystem Bioconductor is the canonical repository of R packages for genomics analysis, hosting tools for sequencing, expression, epigenomics, and single-cell work. dplyr integrates naturally with the reporting and workflow side of that ecosystem. Automated RNA-seq pipelines such as CANEapp wrap R packages including edgeR and DESeq2 for differential expression and noncoding RNA discovery [5], and the results tables those tools produce are exactly the kind of mid-sized, analysis-ready tables where dplyr's grammar is pleasant. Downstream, interactive dashboard packages such as i2dash turn processed omics results into web-based visualizations for facilities and collaborators [6], and those result tables pass through dplyr pipelines cleanly. ## Head-to-Head on the Criteria That Decide Real Choices ### Import Speed For reading delimited genomic files, `fread()` is consistently the fastest general-purpose reader in the R ecosystem, and multithreading widens the gap. If your pipeline ingests many per-chromosome association files or per-sample variant summaries, fread with `select` and `nThread` is the default choice. `readr::read_csv()` remains a good option when you want strict, reproducible column type specifications, and its errors on unexpected values are more informative than fread's silent type guesses. ### Memory Behavior This is the decisive criterion for the "large" in large genomic data. data.table's in-place updates mean peak memory stays close to the size of the data. dplyr's copy-on-modify means peak memory grows with the number and width of your transformations. The BESSiE authors identified RAM pressure as a defining limitation of R for large genomic marker data [3], and the same limitation drives tool design across the field. PRSice-2's headline improvement over its predecessor was memory efficiency at biobank scale [1], and population-scale pedigree tooling such as LT-FGRS emphasizes manageable computational cost as a benchmarking requirement [2]. When your table is large enough that a single extra copy threatens the available RAM, data.table is not an optimization, it is the difference between a script that runs and one that does not. ### Joins and Indexing Both packages perform joins correctly. The differences are speed at scale and persistent indexing. data.table's keyed joins maintain the index across operations, so a table you join against repeatedly, such as a sample metadata table or a variant annotation table, pays the sorting cost once. dplyr joins sort on demand each time. For a one-time merge of a phenotype table with 500,000 rows against a variant table with 20 million rows, both finish quickly. For a pipeline that performs that merge per chromosome across 22 chromosomes per trait across 50 traits, the keyed approach saves the repeated sort. ### Readability and Review dplyr wins clearly. Its verb grammar maps to the language of analysis plans, and code review catches logic errors faster in piped dplyr chains than in dense data.table bracket expressions. This matters in regulated or collaborative settings. The JLNet framework, built as an R package for analyzing national geriatric networks such as Medicare claims, explicitly promotes easy implementation as a design goal alongside its statistical machinery [7], reflecting a broader pattern: as R-based methods move into multi-center applied settings, code clarity becomes a stated requirement, not a preference. ### Grouped and Rolling Operations For grouped summaries, both are fast on moderate data. On very large tables, data.table's grouped operations run at C level and avoid the intermediate grouping structures dplyr creates. Rolling window operations along ordered genomic positions, such as computing a running mean of test statistics across base pair coordinates, are a data.table strength because the by-reference model and ordered keys make incremental updates natural. ### Ecosystem and Interoperability dplyr sits at the center of the largest package ecosystem in R. [Data wrangling](/blog/data-analysis/what-is-data-wrangling) flows into ggplot2 plotting, tidyr reshaping, and broom model tidying without friction. data.table is more self-contained, though it is used internally by many high-performance packages, so you often use data.table without knowing it. For bioinformatics, Python's growing role in [multi-omics analysis](/knowledge/bioinformatics/multi-omics-integration-a-practical-workflow-for-combining-proteomics-metabolomics-and-epigenomi), exemplified by tools like PyComplexHeatmap built on the pandas and matplotlib stack [8], means R teams should also plan for interconversion, and both data.table and tibbles convert to and from pandas-friendly formats well. ### Scaling Beyond RAM Neither package solves out-of-memory analysis by itself. The practical strategies differ: - data.table: import only needed columns with `fread(select = ...)`, process files in chunks keyed by chromosome or batch, and aggregate early so downstream tables shrink. - dplyr: push computation to a backend with `dbplyr` or `arrow`, so the heavy work runs in a database or against Parquet files on disk. A well-designed hybrid uses data.table for ingestion and chunked reduction, writes compact results, then switches to dplyr for the analysis and reporting layer. The CoreFlow platform, which manages proteomics and other large-scale biology data through relational databases with R scripts for processing and modeling, illustrates this layered architecture in practice [9]. ## Worked Scenarios ### Scenario 1: Quality Control of Many GWAS Summary Statistic Files You receive 500 per-chromosome summary statistics files from a meta-analysis. Each file has 8 million rows. You must check formatting, flag variants with extreme effect sizes, verify allele consistency across studies, and produce plots. The data.table approach handles this well because the workload is import-heavy and per-file. Read each file with `fread(select = c("SNP", "A1", "A2", "BETA", "SE", "P"), nThread = 8)`, apply the filter checks with in-place `:=` flags, aggregate the flags with a single grouped `by` summary, and write per-file QC reports with `fwrite()`. This mirrors the workflow GWAtoolbox formalized, which standardizes checks on data formatting, result quality, and cross-study consistency, and returns extensive statistics and plots for inspecting individual files and comparing between studies [4]. Because each file is processed and released, peak memory never holds more than one file plus the running summary. A dplyr version of the same logic works, but the per-file import is slower and the many mutation steps add memory churn inside each 8-million-row table. ### Scenario 2: Joining Phenotypes to Genotype-Derived Scores at Biobank Scale You have a phenotype table with 500,000 individuals and a polygenic risk score table with the same individuals, plus a covariate table from a separate source. You need a single analysis table keyed by individual ID, filtered to unrelated individuals of European ancestry, with all covariates merged. Two joins and a filter decide the design. If this is a one-time assembly, dplyr's `left_join()` chain is perfectly adequate and produces code your collaborators can audit: ```r analysis_df <- pheno %>% inner_join(prs, by = "sample_id") %>% left_join(covariates, by = "sample_id") %>% filter(related == FALSE, ancestry == "EUR") ``` If this assembly runs repeatedly, for instance once per trait in a PRSice-2-style analysis where multiple traits are evaluated at multiple score thresholds [1], the data.table keyed-join version amortizes the index cost and keeps the memory profile flat. gJLS2, an R package for joint location and scale analysis in GWAS, similarly targets streamlined genome-wide analysis at biobank scale, where per-marker or per-trait loop efficiency compounds into hours of saved compute [10]. ### Scenario 3: Reshaping Proteomics Intensity Tables A mass spectrometry experiment yields a long table of peptide intensities with missing values, because less abundant peptides are quantified in only a subset of runs [11]. You need to pivot to a peptide-by-sample matrix, summarize to the protein level, and track per-experiment quantification counts. This is mid-sized data, typically millions of rows, and dplyr plus tidyr is the natural fit. The pipeline is readable, the pivots are clear, and the memory cost of copies is tolerable. The coADAPTr package, built for proteome-wide covalent labeling analysis in R, demonstrates the value of a streamlined, scriptable quantitation workflow over manual spreadsheet manipulation at this scale [12]. Reaching for data.table here buys speed you do not need at the price of syntax your wet-lab collaborators may not read. ### Scenario 4: Sustaining a Multi-Year Analysis Pipeline Your group maintains a pipeline that runs monthly, ingests new sequencing batches, updates copy-number and annotation tables, and publishes results to an internal dashboard. Code must survive staff turnover. The sustainable design assigns each package to the layer where it is strongest. data.table handles the batch ingestion and the keyed updates to large accumulating tables, in the same spirit as the suite of helper tools built around the ASCAT R package for copy-number analysis, which supports both one-shot execution and approaches suitable for large-scale compute farms [13]. dplyr handles the transformation, summarization, and reporting layer that feeds visual outputs, in the pattern used by pipeline-plus-dashboard systems such as CoreFlow for [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) and i2dash for visualization delivery [6] [9]. Documenting which layer uses which package, and standardizing on `setDT()` at the boundary, prevents the two grammars from colliding in the same function. ## A Benchmark You Can Run Yourself Published microbenchmarks age quickly and depend heavily on hardware, file layout, and column types. The reliable practice is to benchmark on your own data before committing a pipeline. The script below times the same operations in both packages on a synthetic variant table: ```r library(data.table) library(dplyr) library(bench) n <- 5e7 # 50 million rows, roughly a large multi-chromosome summary file set.seed(42) dt <- data.table( chr = sample(1:22, n, replace = TRUE), pos = sample.int(2.5e8, n, replace = TRUE), beta = rnorm(n), p = runif(n) ) df <- as.data.frame(dt) mark( dt_filter = dt[p < 0.001 & chr == 5], dp_filter = df %>% filter(p < 0.001, chr == 5), dt_group = dt[, .(m = mean(beta)), by = chr], dp_group = df %>% group_by(chr) %>% summarize(m = mean(beta)), iterations = 5 ) ``` Typical outcomes on this kind of workload, and the pattern most practitioners report, are that data.table completes filtering and grouped operations several times faster than dplyr with a smaller memory footprint, that the gap narrows on smaller tables, and that dplyr is fully adequate below roughly 10 million rows. Run the benchmark on your actual file sizes and hardware before drawing conclusions for your project, and repeat it three times to see the variance. ## When to Use data.table ![Decision path asking about table size, repeated joins and database storage to pick data.table, dplyr or both.](/article-images/illustrations/data-table-vs-dplyr-genomics-tool-choice-triage.webp) The decision list for when to use data.table, drawn from the criteria above: 1. Any table larger than a few gigabytes, where an extra copy during a mutation can exhaust RAM. 2. Pipelines that repeatedly join against a common table, where a persistent key pays for itself. 3. Ingestion of many large delimited files, where `fread()` with `nThread` and `select` dominates all alternatives. 4. Hot loops inside packages or long-running jobs, where per-iteration overhead compounds. 5. Per-chromosome or per-batch chunked processing of files that individually approach RAM limits. 6. Ordered position-based operations along chromosomes, such as sliding window summaries. And the corresponding list for dplyr: 1. Tables that fit comfortably in RAM, under roughly 1 to 2 GB. 2. Exploratory analysis where you iterate fast and readability keeps you honest. 3. Pipelines shared with collaborators who need to audit the logic. 4. Workflows feeding ggplot2, tidyr, Quarto reports, and Shiny applications. 5. Data that lives in a database or Parquet files, where `dbplyr` or `arrow` push computation to the backend. 6. Teaching and methods documentation, where the grammar maps to the analysis plan. Most real genomics projects in R end up using both, each in its layer. ## Common Mistakes and Limitations ![Flowchart showing conversion with setDT, data.table ingestion, writing compact results, then as.data.frame for dplyr reporting.](/article-images/illustrations/data-table-vs-dplyr-genomics-layer-boundary-workflow.webp) - **Mixing the two grammars on the same object without conversion.** Piping a data.table into dplyr works but silently disables by-reference performance and can trigger copies. Convert explicitly with `setDT()` or `as.data.table()` at the layer boundary, and convert back with `as.data.frame()` when handing results to dplyr or Bioconductor code. - **Assuming dplyr code is slow everywhere.** On tables under a few million rows, the performance difference is usually seconds, and the readability gain outweighs it. Choosing data.table by reflex in every script makes code harder to maintain for no measurable gain. - **Forgetting that := modifies the original table.** A data.table passed into a function and updated with `:=` is changed in the caller's environment too. This causes duplicate-column and corrupted-annotation bugs. Use `copy()` when a function must not alter its input. - **Keying without rekeying after modification.** If you `setkey()` and then append or modify the key columns, the index is stale and joins can silently return wrong or incomplete results. Rekey after any change to key columns. - **Ignoring column types on import.** fread's type guessing can misparse chromosomes with X, Y, and MT values as mixed types, or crush long variant identifiers. Specify `colClasses` explicitly for production pipelines, the same discipline `readr` enforces by default. - **Treating memory savings as analysis savings.** A fast data.table pipeline that filters p-values without multiple-testing correction or strand checking produces wrong results faster. Package-level QC frameworks such as GWAtoolbox exist because formatting and consistency checks are separable from, and prior to, any speed optimization [4]. - **Overlooking when R itself is the wrong layer.** R's ceiling is real. The BESSiE developers built a parameter-file-driven, command-line tool outside interactive R specifically because script-based R could not comfortably handle large-scale genomic marker analysis [3], and PRSice-2's efficiency gains required a dedicated C++ implementation for biobank-scale PRS computation [1]. When a single table exceeds your machine's RAM even in data.table, move to chunked processing, a database backend, or command-line tooling rather than fighting the limit. - **Benchmarking on toy data.** A 100,000-row benchmark tells you nothing about a 50-million-row production job, because the relative costs of copying, hashing, and indexing change with size. Always benchmark at production scale on representative files. ## Frequently Asked Questions ### Is data.table always faster than dplyr for genomic data? No. data.table is generally faster and more memory-efficient on large tables, especially for filtering, grouping, and joins at tens of millions of rows or more. On small to mid-sized tables, under a few million rows, the difference is often seconds or less, and dplyr's readability makes it the better engineering choice there. ### Can I mix data.table and dplyr in the same script? Yes, and most real pipelines do. Convert explicitly with `setDT()` when entering data.table code and `as.data.frame()` or `tibble()` when returning to dplyr. Avoid piping a data.table directly through long dplyr chains, because that path loses the by-reference performance benefit. ### Do I need data.table for single-cell RNA-seq data? Not for the expression matrix itself, which Bioconductor and single-cell packages store in sparse matrix formats rather than data frames. data.table and dplyr both remain useful for cell-level metadata, which can reach millions of rows in large atlases, and at that scale data.table's in-place updates help. ### How does data.table handle files larger than RAM? data.table does not process a file larger than RAM in one pass. The standard strategies are importing only needed columns with `fread(select = ...)`, processing the file in chunks keyed by chromosome or batch, and writing compact intermediate results. For sustained out-of-memory work, pair data.table ingestion with a database backend such as DuckDB. ### Which tool should I learn first for R in bioinformatics? Learn dplyr first. Its verb grammar matches the language of analysis plans, it integrates with the tidyverse and Bioconductor tooling you will use daily, and most educational genomics material assumes it. Add data.table when your tables grow past a few gigabytes or your pipeline joins large tables repeatedly. ### Does dplyr work with Bioconductor objects? Partly. dplyr verbs work directly on the data frames and tibbles inside Bioconductor workflows, such as colData tables and result data frames from DESeq2 or edgeR. They do not operate on core Bioconductor containers like SummarizedExperiment or SingleCellExperiment themselves, so you extract the relevant slot, wrangle it with dplyr, and write it back or pass it onward. ## Sources 1. [PRSice-2: Polygenic Risk Score software for biobank-scale data.](https://pubmed.ncbi.nlm.nih.gov/31307061/) 2. [LT-FGRS: a unifying R-package for the estimation of family-based genetic liabilities at population-scale.](https://pubmed.ncbi.nlm.nih.gov/42367923/) 3. [BESSiE: a software for linear model BLUP and Bayesian MCMC analysis of large-scale genomic data.](https://pubmed.ncbi.nlm.nih.gov/27590176/) 4. [GWAtoolbox: an R package for fast quality control and handling of genome-wide association studies meta-analysis data.](https://pubmed.ncbi.nlm.nih.gov/22155946/) 5. [CANEapp: a user-friendly application for automated next generation transcriptomic data analysis.](https://pubmed.ncbi.nlm.nih.gov/26758513/) 6. [i2dash: Creation of Flexible, Interactive, and Web-based Dashboards for Visualization of Omics Data.](https://pubmed.ncbi.nlm.nih.gov/34280547/) 7. [A joint learning framework for analyzing data from national geriatric centralized networks: A new toolbox deciphering real-world complexity.](https://pubmed.ncbi.nlm.nih.gov/41232786/) 8. [PyComplexHeatmap: a Python package to visualize multimodal genomics data.](https://pubmed.ncbi.nlm.nih.gov/38454967/) 9. [CoreFlow: a computational platform for integration, analysis and modeling of complex biological data.](https://pubmed.ncbi.nlm.nih.gov/24503186/) 10. [gJLS2: an R package for generalized joint location and scale analysis in X-inclusive genome-wide association studies.](https://pubmed.ncbi.nlm.nih.gov/35201341/) 11. [Detecting differential protein expression in large-scale population proteomics.](https://pubmed.ncbi.nlm.nih.gov/24928210/) 12. [Covalent Labeling Automated Data Analysis Platform for High Throughput in R (coADAPTr): A Proteome-Wide Data Analysis Platform for Covalent Labeling Experiments.](https://pubmed.ncbi.nlm.nih.gov/39356573/) 13. [ascatNgs: Identifying Somatically Acquired Copy-Number Alterations from Whole-Genome Sequencing Data.](https://pubmed.ncbi.nlm.nih.gov/27930809/)