0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

go1.27でuuid標準化、google/uuidよりゼロアロケーションで22%速い

0
Posted at

はじめに

対象読者は、GoでUUIDを生成する処理を持っていて github.com/google/uuid に依存しているエンジニアです。Go 1.27（2026年8月リリース）で標準ライブラリに uuid パッケージが追加されました。今まで外部ライブラリ頼みだった機能が言語標準に入ったとき、まず気になるのは「乗り換える価値があるのか」です。API互換性・生成速度・バイナリサイズの3点を、実際にGo 1.27を導入してベンチマークを取り、google/uuid v1.6.0と同じ条件で比較しました。

結果一覧（先に結論）

比較項目 標準ライブラリ（uuid） google/uuid（v1.6.0） 差分
API互換性 New/NewV7/Parse/String・RFC 9562準拠 同左 ほぼ同一。移行コストは低い
New() 生成速度 82.56 ns/op・0 allocs 105.8 ns/op・1 alloc 標準が 約22%速い
NewV7() 生成速度 122.5 ns/op・0 allocs 188.2 ns/op・1 alloc 標準が 約35%速い
Parse() 速度 37.45 ns/op 38.24 ns/op ほぼ同等
バイナリサイズ 2,690,216 bytes 3,245,532 bytes 標準が 約17%（555KB）小さい

各項目の実測手順は以下で示します。

比較の条件

項目 標準ライブラリ（uuid） google/uuid（v1.6.0）
Goバージョン go1.27.0 linux/amd64 同左
実行環境 Intel(R) Xeon(R) Processor @ 2.80GHz 同左
ベンチマーク方法 go test -bench=. -benchmem 同左
比較日 2026年8月28日時点 v1.6.0固定

Go 1.27は公式リリースノートに記載の通り、encoding/json/v2・crypto/mldsa（ポスト量子署名）・uuid・実験的な simd パッケージが新規追加されています。このうち uuid パッケージは以下のAPIを持ちます（go doc uuid で確認済み）。

type UUID [16]byte
    func Max() UUID
    func MustParse(s string) UUID
    func New() UUID
    func NewV4() UUID
    func NewV7() UUID
    func Nil() UUID
    func Parse(s string) (UUID, error)
    func (u UUID) Compare(v UUID) int
    func (u UUID) String() string

google/uuid とほぼ同じ形（16バイト配列・New/NewV7/Parse/String）で、既存コードの移行コストは低そうです。実際に両方を同じプログラムから呼び出して確認しました。

package main

import (
	"fmt"

	guuid "github.com/google/uuid"
	"uuid"
)

func main() {
	su := uuid.New()
	sv7 := uuid.NewV7()
	fmt.Println("stdlib New():   ", su.String())
	fmt.Println("stdlib NewV7(): ", sv7.String())

	parsed, err := uuid.Parse(su.String())
	if err != nil {
		panic(err)
	}
	fmt.Println("stdlib Parse ok, equal:", parsed == su)

	gu := guuid.New()
	gv7, _ := guuid.NewV7()
	fmt.Println("google New():   ", gu.String())
	fmt.Println("google NewV7(): ", gv7.String())
}

実行結果:

stdlib New():    6176239f-af86-4a9d-9d2f-973f40486fdb
stdlib NewV7():  01a0473d-1f65-75e7-bdb6-9879948728fa
stdlib Parse ok, equal: true
google New():    2267f640-7a02-4720-9614-862966ec6588
google NewV7():  01a0473d-1f65-7672-a7a8-b382745d596d

出力されるUUIDの形式（RFC 9562準拠のv4/v7）自体に差はありません。UUID 型は [16]byte のcomparableな型として定義されており、== で直接比較できる点もgoogle/uuidと同じでした。

生成速度をベンチマークで測る

go test -bench=. -benchmem で、UUID生成（New/NewV7）とパース（Parse）を1万回以上実行した平均を取りました。

実測結果:

処理 標準ライブラリ google/uuid 差分
New() 82.56 ns/op・0 B/op・0 allocs 105.8 ns/op・16 B/op・1 alloc 標準が約22%速く、アロケーションゼロ
NewV7() 122.5 ns/op・0 B/op・0 allocs 188.2 ns/op・16 B/op・1 alloc 標準が約35%速く、アロケーションゼロ
Parse() 37.45 ns/op・0 B/op・0 allocs 38.24 ns/op・0 B/op・0 allocs ほぼ同等（誤差の範囲）

生成系は標準ライブラリが明確に速く、しかもヒープアロケーションが発生しません。google/uuid は内部で []byte を都度確保しているのに対し、標準ライブラリは値型のまま完結する実装になっているようです。パースはどちらもゼロアロケーションで、速度差はほぼありません。大量にUUIDを発行するバッチ処理やIDジェネレータでは、この差が積み重なって効いてきます。

バイナリサイズも比較する

依存を1つ削れるとバイナリサイズがどれだけ変わるかも、実際にビルドして確認しました。同じ内容（UUIDを1つ生成して標準出力に書くだけ）のプログラムを、標準ライブラリのみの版と google/uuid を import した版でそれぞれ go build しています。

ビルド バイナリサイズ
標準ライブラリのみ 2,690,216 bytes
google/uuid 同梱 3,245,532 bytes

差は約555KB（google/uuid 同梱に対して標準ライブラリのみは約17%小さい）でした。google/uuid 自体は小さなライブラリですが、依存を1つ増やすとGoのリンカが持ち込むランタイム部分も含めてこの程度の差が出ます。CLIツールやLambda関数のようにバイナリサイズを気にする用途では無視できない数字です。

著者視点: 乗り換え判断はGo 1.27を前提にできるかどうかで決まる

実際に手を動かしてみて感じたのは、機能面での差はほぼ「誤差の範囲」ということです。パース速度は同等、生成されるUUIDのフォーマットも同じRFC 9562準拠。乗り換えの決め手になるのは、速度でもサイズでもなく Go 1.27を前提にできるかどうか でした。

  • 新規プロジェクトでGo 1.27以降を前提にできるなら、外部依存を1つ減らせて生成速度も上がる標準ライブラリを使わない理由がありません
  • 既存プロジェクトで go.mod の go ディレクティブがまだ1.24や1.25の場合、標準ライブラリへの移行はGoのアップグレードとセットになります。google/uuid を使い続けるコストと、Goバージョンを上げるコストを天秤にかける判断が必要です
  • NewV7()（時系列ソート可能なUUID）を多用するライブラリ・フレームワークが google/uuid の型（guuid.UUID）を前提にAPIを公開している場合、標準ライブラリの uuid.UUID 型とは別の型なので、型変換のための String()→Parse() の往復が必要になる点は移行コストとして見落としやすいところです

Go標準ライブラリへの新パッケージ追加は「外部ライブラリの実装がこなれてから取り込む」傾向があり、UUIDのようによく使われる機能が標準化されるのは、エコシステム全体としては歓迎できる動きだと感じました。

まとめ

Go 1.27で追加された標準 uuid パッケージは、google/uuid とAPIの形がほぼ同じで移行コストが低く、生成速度は22〜35%速くヒープアロケーションもゼロという実測結果でした。バイナリサイズも約17%削減できます。既存の google/uuid 依存をすぐに置き換える必要はありませんが、Go 1.27以降を前提にできる新規プロジェクトでは標準ライブラリを第一候補にする価値があります。

関連記事

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?