分步骤记录整合耗时并核对算法与对象大小

“整合跑了很久”可能指归一化、缩放、PCA、整合本身，也可能是UMAP或保存文件。只在最后看一次总耗时，无法知道应调整哪一个步骤。本文将Seurat layer工作流拆成可记录阶段，帮助把性能问题与算法选择分开。

示例采用支持Assay5的Seurat版本，输入是已完成质量核查、只有一个RNA counts层的内存型对象，并有可靠的sample_id列。代码使用当前公开的IntegrateLayers接口；旧anchor对象流程与新的layer流程不要混在同一份脚本里。磁盘矩阵的保存和物化问题需要另行检查，不能直接照搬内存对象的估算。

先确认整合目标和输入分层

写清哪些变量代表技术批次，哪些代表真实生物差异。将处理条件、疾病状态或组织来源直接当作需要完全消除的批次，可能损失研究信号。性能优化之前，需要方法本身适用于数据；最快完成的一次运行不一定是合适的整合。

检查每个样本细胞数、共同特征、assay与layer状态。一个已经按样本拆开的assay，不应再次无条件split。若对象还保存多份不再需要的整合结果，先确认保留用途并归档；不要在同一个活动对象中不断叠加候选方法后，再把对象膨胀都归结为算法慢。

给每个阶段建立时间记录

下面的计时包装器记录墙钟时间和返回对象的近似大小。对象大小不能替代R进程的峰值内存，因此运行整份脚本时还要配合外部统计。示例中的维度上限是演示起点，实际分析要结合数据与目标选择。

library(Seurat)
obj <- readRDS("qc-counts-only.rds")
DefaultAssay(obj) <- "RNA"
stopifnot(inherits(obj[["RNA"]], "Assay5"),
          identical(Layers(obj[["RNA"]]), "counts"),
          "sample_id" %in% colnames(obj[[]]), !anyNA(obj$sample_id),
          all(nzchar(obj$sample_id)), length(unique(obj$sample_id))>=2L)
write.csv(data.frame(step=character(), elapsed=numeric(), bytes=numeric()),
          "stage-times.csv", row.names=FALSE)
measure <- function(label, expr) {
  timing <- system.time(ans <- force(expr))
  row <- data.frame(step=label, elapsed=unname(timing["elapsed"]),
                    bytes=as.numeric(object.size(ans)))
  write.table(row, "stage-times.csv", sep=",", append=TRUE,
              col.names=FALSE, row.names=FALSE)
  ans
}
obj[["RNA"]] <- split(obj[["RNA"]], f=obj$sample_id)
obj <- measure("normalize", NormalizeData(obj))
obj <- measure("features", FindVariableFeatures(obj))
obj <- measure("scale", ScaleData(obj, features=VariableFeatures(obj)))
npcs <- min(30L, length(VariableFeatures(obj))-1L,
            min(table(obj$sample_id))-1L)
stopifnot(npcs >= 2L)
obj <- measure("pca", RunPCA(obj, npcs=npcs))
saveRDS(obj, "prepared-before-integration.rds")
obj <- measure("rpca", IntegrateLayers(obj, method=RPCAIntegration,
              orig.reduction="pca", new.reduction="integrated.rpca",
              dims=seq_len(npcs), verbose=TRUE))
saveRDS(obj, "integrated-rpca.rds")

怎样读取计时与内存证据

使用/usr/bin/time -v Rscript your-script.R记录整段任务；若最高内存阶段仍不清楚，可从已经保存的准备节点启动单一阶段进行测量。阶段对象大小较小，不保证构建它的过程中没有出现更大的临时矩阵或并行副本。

如果CPU未满，先查看实际算法、等待I/O与个人资源额度，而不是直接追加核心。若出现future变量导出上限，按完整错误区分导出设置和物理内存问题。若报错与特征缺失、样本太小或层结构有关，先修复输入和方法条件，硬件扩容不能替代这些检查。

验收整合结果和下一步

确认目标reduction存在，细胞名和元数据对应，保存文件可以重新读取。进一步用批次、样本和可信细胞类型分别观察结果，检查已知群体是否保留。不能以所有样本在图上混得越均匀越好作为唯一标准，也不能用整合低维表示直接代替所有差异分析所需的表达数据。

总细胞数之外还要记录批次数

两个项目总细胞数相近，并不意味着整合任务相同。样本数量、样本之间可对应的细胞结构、选用维度和参考策略，都可能影响工作量与结果。阶段记录里应包含这些条件，而不是只填一个细胞总数。

若想增加并行度，应先核对该方法和版本实际使用的并行路径，再用同输入比较。更多worker可能增加对象副本，某些阶段也未必从更多核心受益。先保留一个可解释的基线，再逐项修改并发，比同时调大核心、内存和方法参数更容易定位问题。

有了阶段时间表，再针对实际必要阶段评估CPU、内存和工作盘。流程与方法条件合理、必要资源仍超出本地容量时，可以准备整合方法、样本与细胞规模、阶段日志和使用期限，沟通大内存CPU服务器方案。

参考与版本核对

• Seurat：layer整合工作流
• Seurat：IntegrateLayers参考
• Seurat：ScaleData参考
• GNU Time：内存资源统计