前面的底线：不，目前没有办法在不损害唯一性的核心前提的情况下加速大量具有uuid 的 UUID 的生成。 （即使用uuid。）
事实上，您使用use.time=FALSE 的建议会产生严重的不良后果（在Windows 上）。见下文。
有可能在规模上获得更快的性能，但 uuid 不行。见下文。
uuid 在 Windows 上
uuid::UUIDgenerate 的性能应该考虑到操作系统。更具体地说，随机性的来源。看性能很重要，是的，在哪里：
library(microbenchmark)
microbenchmark(
rf=replicate(1000, uuid::UUIDgenerate(FALSE)),
rt=replicate(1000, uuid::UUIDgenerate(TRUE)),
sf=sapply(1:1000, function(ign) uuid::UUIDgenerate(FALSE)),
st=sapply(1:1000, function(ign) uuid::UUIDgenerate(TRUE))
)
# Unit: milliseconds
# expr min lq mean median uq max neval
# rf 8.675561 9.330877 11.73299 10.14592 11.75467 66.2435 100
# rt 89.446158 90.003196 91.53226 90.94095 91.13806 136.9411 100
# sf 8.570900 9.270524 11.28199 10.22779 12.06993 24.3583 100
# st 89.359366 90.189178 91.73793 90.95426 91.89822 137.4713 100
...所以使用use.time=FALSE 总是更快。 （我将sapply 示例与您的答案代码进行比较，以表明replicate 永远不会变慢。除非您觉得出于某种原因需要数字参数，否则请在此处使用replicate。）
但是，有一个问题：
R.version[1:3]
# _
# platform x86_64-w64-mingw32
# arch x86_64
# os mingw32
length(unique(replicate(1000, uuid::UUIDgenerate(TRUE))))
# [1] 1000
length(unique(replicate(1000, uuid::UUIDgenerate(FALSE))))
# [1] 20
鉴于 UUID 旨在每次调用时都是唯一的，这令人不安，并且是 Windows 上随机性不足的症状。 （WSL 是否为此提供了出路？另一个研究机会......）
uuid 在 Linux 上
为了比较，在非 Windows 平台上的结果相同：
microbenchmark(
rf=replicate(1000, uuid::UUIDgenerate(FALSE)),
rt=replicate(1000, uuid::UUIDgenerate(TRUE)),
sf=sapply(1:1000, function(ign) uuid::UUIDgenerate(FALSE)),
st=sapply(1:1000, function(ign) uuid::UUIDgenerate(TRUE))
)
# Unit: milliseconds
# expr min lq mean median uq max neval
# rf 20.852227 21.48981 24.90932 22.30334 25.11449 74.20972 100
# rt 9.782106 11.03714 14.15256 12.04848 15.41695 100.83724 100
# sf 20.250873 21.39140 24.67585 22.44717 27.51227 44.43504 100
# st 9.852275 11.15936 13.34731 12.11374 15.03694 27.79595 100
R.version[1:3]
# _
# platform x86_64-pc-linux-gnu
# arch x86_64
# os linux-gnu
length(unique(replicate(1000, uuid::UUIDgenerate(TRUE))))
# [1] 1000
length(unique(replicate(1000, uuid::UUIDgenerate(FALSE))))
# [1] 1000
（我对use.time=FALSE 在 linux 上花费的时间是 windows 上的两倍……有点好奇……）
使用 SQL 服务器生成 UUID
如果您可以访问 SQL 服务器（几乎可以肯定...参见 SQLite ...），那么您可以通过使用 服务器的 UUID 生成实现来处理这个规模问题，认识到存在一些细微差别。
（旁注：有“V4”（完全随机）、“V1”（基于时间）和“V1mc”（基于时间并包括系统的 MAC 地址）UUID。uuid 给出 V4 如果@ 987654339@ 和 V1 否则，编码系统的 mac 地址。）
一些性能比较在 windows 上（所有时间都以秒为单位）：
# n uuid postgres sqlite sqlserver
# 1 100 0 1.23 1.13 0.84
# 2 1000 0.05 1.13 1.21 1.08
# 3 10000 0.47 1.35 1.45 1.17
# 4 100000 5.39 3.10 3.50 2.68
# 5 1000000 63.48 16.61 17.47 16.31
SQL 的使用有一些开销，在大规模使用时不会花费很长时间来克服。
-
PostgreSQL 需要uuid-ossp 扩展，可以安装
CREATE EXTENSION "uuid-ossp"
一旦安装/可用，您可以生成n UUID：
n <- 3
pgcon <- DBI::dbConnect(...)
DBI::dbGetQuery(pgcon, sprintf("select uuid_generate_v1mc() as uuid from generate_series(1,%d)", n))
# uuid
# 1 53cd17c6-3c21-11e8-b2bf-7bab2a3c8486
# 2 53cd187a-3c21-11e8-b2bf-dfe12d92673e
# 3 53cd18f2-3c21-11e8-b2bf-d3c64c6ad73f
存在其他 UUID 函数。 https://www.postgresql.org/docs/9.6/static/uuid-ossp.html
-
SQLite 的功能有限，但这种 hack 对于 V4 样式的 UUID（长度 n）来说已经足够了：
sqlitecon <- DBI::dbConnect(RSQLite::SQLite(), ":memory:") # or your own
DBI::dbGetQuery(sqlitecon, sprintf("
WITH RECURSIVE cnt(x) as (
select 1 union all select x+1 from cnt limit %d
)
select (hex(randomblob(4))||'-'||hex(randomblob(2))||'-'||hex(randomblob(2))||'-'||hex(randomblob(2))||'-'||hex(randomblob(6))) as uuid
from cnt", n))
# uuid
# 1 EE6B08DA-2991-BF82-55DD-78FEA48ABF43
# 2 C195AAA4-67FC-A1C0-6675-E4C5C74E99E2
# 3 EAC159D6-7986-F42C-C5F5-35764544C105
将其格式化为相同的格式需要一点点痛苦，充其量只是一种精细。如果不坚持这种格式，您可能会发现性能上的小幅提升。）
SQL Server 需要临时创建一个表（使用newsequentialid()），在其中生成一个序列，提取自动生成的 ID，然后丢弃该表。有点过头了，特别是考虑到使用 SQLite 的易用性，但是 YMMV。 （没有提供代码，它不会增加太多。）
其他注意事项
除了执行时间和足够的随机性之外，关于使用非连续 UUID 指示性能影响的数据库表，还有各种讨论（暂时未引用）。这与索引页面等有关，超出了此答案的范围。
但是，假设这是真的……假设大约在同一时间插入的行（时间相关）通常被分组在一起（直接或子分组），那么保持同一天是一件好事在同一数据库索引页中具有 UUID 键的数据，因此 V4（完全随机）UUID 可能会降低大型组（和大型表）的数据库性能。出于这个原因，我个人更喜欢 V1 而不是 V4。
其他（仍未引用）讨论认为在 UUID 中包含可直接追踪的 MAC 地址是对内部信息的轻微破坏。出于这个原因，我个人倾向于 V1mc 而不是 V1。
（但我还没有办法用RSQLite 很好地做到这一点，所以我依赖于附近有postgresql。幸运的是，我使用postgresql 来处理我保留一个实例的其他事情Windows 上的泊坞窗。）