为何GNU parallel执行该命令时与单CPU xargs速度相当？

我来帮你拆解下这两个问题的根源，以及对应的解决办法，都是生产环境里验证过的实用方案：

一、搞定GNU Parallel CPU使用率上不去的问题 #

你说parallel和单核心xargs速度差不多、CPU没超过100%，大概率是这几个原因：

1. 任务粒度太细：如果单个XML文件很小，xsltproc转换耗时极短，进程启动的开销反而抵消了并行的收益。
2. 默认并发数没匹配核心数：parallel默认可能没用到你全部的CPU核心。

试试这几个调整：

• 明确指定并发数：用-j参数直接设置和CPU核心数一致的并发数（比如8核就加-j8）：

  parallel -j8 xsltproc your_transform.xsl {} > {.}.csv ::: *.xml
  

• 批量处理小文件：用-X参数让parallel把多个XML打包给单个xsltproc进程，减少进程启动开销：

  parallel -j8 -X xsltproc your_transform.xsl {} > batch_{#}.csv ::: *.xml
  

• 排查IO瓶颈：如果文件在机械硬盘上，IO可能拖了后腿。可以先把文件拷到内存tmpfs再处理：

  temp_dir=$(mktemp -d -t xml_cache.XXXXXX)
  cp *.xml "$temp_dir"
  cd "$temp_dir"
  parallel -j8 xsltproc your_transform.xsl {} > {.}.csv ::: *.xml
  

二、解决xargs -P8输出交错的问题 #

xargs并行时多个进程同时往stdout写，必然会导致行混乱，核心思路是让每个任务先输出到独立临时文件，最后再合并，或者直接用支持有序输出的工具：

方法1：临时文件中转（纯xargs方案） #

# 创建临时目录存单个CSV
temp_dir=$(mktemp -d)
# 并行转换每个XML到单独文件
ls *.xml | xargs -P8 -I{} xsltproc your_transform.xsl {} > "$temp_dir/{}.csv"
# 合并：先写表头，再追加所有内容（跳过其他文件的表头）
head -n1 "$temp_dir/$(ls *.xml | head -n1).csv" > merged.csv
tail -q -n+2 "$temp_dir"/*.csv >> merged.csv
# 清理临时文件
rm -rf "$temp_dir"

方法2：用Parallel的有序输出（更简洁高效） #

其实Parallel本身就支持有序输出，即使任务并行执行，输出也会严格按输入文件的顺序返回，完美避免交错：

parallel -j8 -k xsltproc your_transform.xsl {} ::: *.xml > merged.csv

这里的-k（--keep-order的短参数）是关键，它会让Parallel等待前面的任务完成后再输出结果，最终的合并文件顺序和你输入的XML顺序完全一致，不需要临时文件，一步到位。

三、终极优化：并行转换+去重表头 #

如果你的XSLT转换后每个CSV都带相同的表头，直接合并会重复写入表头，推荐用这个方案：

# 先提取第一个文件的表头写入最终文件
head -n1 <(xsltproc your_transform.xsl $(ls *.xml | head -n1)) > merged.csv
# 并行转换所有文件，跳过表头再追加到最终文件
parallel -j8 -k --skip-first-line xsltproc your_transform.xsl {} ::: *.xml >> merged.csv

--skip-first-line会自动跳过每个转换结果的第一行（表头），既保留并行速度，又保证最终文件只有一份表头。

内容的提问来源于stack exchange，提问作者bluefear