[インデックス 13423] ファイルの概要

このコミットは、Go言語の標準ライブラリ path/filepath パッケージにおけるパスのクリーンアップ処理に関する最適化とバグ修正を目的としています。特に、Windows環境でのパス処理において、既にクリーンアップされたパスに対して Clean 関数が呼び出された際に、不要なメモリ割り当て（アロケーション）を避けるように改善されています。これにより、パフォーマンスの向上とビルドの修正が図られています。

コミット

commit c644a4ddfe9afe8ab79a6d3c776117cdb11dd2b7
Author: Alex Brainman <alex.brainman@gmail.com>
Date:   Sat Jun 30 22:08:53 2012 +1000

    path/filepath: avoid allocation in Clean of cleaned path even on windows (fix build)
    
    R=golang-dev, rsc
    CC=golang-dev
    https://golang.org/cl/6344049

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/c644a4ddfe9afe8ab79a6d3c776117cdb11dd2b7

元コミット内容

path/filepath: avoid allocation in Clean of cleaned path even on windows (fix build)

このコミットメッセージは、path/filepath パッケージの Clean 関数において、Windows環境であっても、既にクリーンアップされたパスに対して再度 Clean が呼び出された場合に、余分なメモリ割り当てを回避するようにしたことを示しています。これにより、ビルドの問題が修正されたと述べられています。

変更の背景

Go言語の path/filepath パッケージは、ファイルパスを操作するためのユーティリティを提供します。Clean 関数は、パスを簡略化し、正規化するために使用されます。例えば、a/./b は a/b に、a/../b は b に、a//b は a/b になります。

このコミットが行われた背景には、おそらく Clean 関数が特定の条件下（特にWindows環境で、既にクリーンアップされたパスが入力として与えられた場合）で、不必要にメモリを再割り当てしてしまうというパフォーマンス上の問題、またはそれに起因するビルドエラーが存在したと考えられます。メモリの再割り当ては、特に頻繁に呼び出される関数においては、パフォーマンスのボトルネックとなる可能性があります。

また、Go言語のクロスプラットフォーム対応において、Windows特有のパス形式（ドライブレター、UNCパスなど）の扱いが複雑であり、それらのパスを効率的かつ正確に処理するための改善が常に求められていました。このコミットは、その一環として、Windows環境での Clean 関数の効率性を向上させることを目的としています。

前提知識の解説

1. `path/filepath` パッケージ

path/filepath パッケージは、Go言語の標準ライブラリの一部であり、オペレーティングシステムに依存しない方法でファイルパスを操作するための機能を提供します。これには、パスの結合、分割、クリーンアップ、絶対パスへの変換などが含まれます。

2. `Clean` 関数

Clean 関数は、パスを簡略化し、正規化するために使用されます。具体的には、以下の処理を行います。

連続するパス区切り文字（例: //）を1つにまとめる。
.（カレントディレクトリ）を削除する。
..（親ディレクトリ）を解決する。
パスの末尾の区切り文字を削除する（ルートディレクトリを除く）。

3. メモリ割り当て（アロケーション）

プログラムが実行中にデータを保存するためにメモリを要求するプロセスです。メモリ割り当ては、ヒープ領域から行われることが多く、頻繁な割り当てと解放はガベージコレクションの負荷を増やし、パフォーマンスを低下させる可能性があります。不要なメモリ割り当てを避けることは、特にパフォーマンスが重要なアプリケーションにおいて、重要な最適化手法です。

4. `lazybuf` 構造体

lazybuf は、このコミットで変更が加えられている内部的なヘルパースタクトです。これは、パスのクリーンアップ処理中に、新しい文字列を構築する際に、可能な限りメモリ割り当てを遅延させる（lazy allocation）ためのものです。入力パスと出力パスが同じである場合、新しいバッファを割り当てることなく、元の文字列のスライスを返すことで効率化を図ります。

5. ボリューム名 (Volume Name)

Windows環境では、パスはドライブレター（例: C:）やUNCパス（例: \\server\share）で始まることがあります。これらは「ボリューム名」と呼ばれ、Unix系システムには存在しない概念です。path/filepath パッケージは、これらのボリューム名を適切に処理する必要があります。

6. `volumeNameLen` 関数 (新設)

このコミットで導入された volumeNameLen 関数は、与えられたパスの先頭にあるボリューム名の長さを返します。これにより、ボリューム名とそれ以降のパス部分を分離し、それぞれを独立して処理することが可能になります。以前は VolumeName 関数がボリューム名自体を文字列として返していましたが、長さだけを返すことで、不要な文字列の生成を避けることができます。

技術的詳細

このコミットの主要な変更点は、path/filepath パッケージ内の Clean 関数と、それに付随するヘルパー構造体 lazybuf、そしてボリューム名処理のロジックにあります。

`lazybuf` 構造体の変更

以前の lazybuf 構造体は、元のパスを s string フィールドで保持していました。このコミットでは、s を path string に変更し、さらに volAndPath string と volLen int という新しいフィールドが追加されました。

type lazybuf struct {
	path       string // 元のパス（ボリューム名を除く部分）
	buf        []byte // 変更があった場合にのみ使用されるバッファ
	w          int    // 書き込み位置
	volAndPath string // 元のパス全体（ボリューム名を含む）
	volLen     int    // ボリューム名の長さ
}

この変更により、lazybuf は元のパス全体とそのボリューム名の長さを保持できるようになり、string() メソッドで最終的なパスを構築する際に、ボリューム名を効率的に結合できるようになりました。

`lazybuf` のメソッドの変更

index(i int) byte:
- 変更前: return b.s[i]
- 変更後: return b.path[i] s フィールドが path に変更されたことに伴う修正です。
append(c byte):
- 変更前: if b.w < len(b.s) && b.s[b.w] == c { ... b.buf = make([]byte, len(b.s)); copy(b.buf, b.s[:b.w]) }
- 変更後: if b.w < len(b.path) && b.path[b.w] == c { ... b.buf = make([]byte, len(b.path)); copy(b.buf, b.path[:b.w]) } ここでも s が path に変更されています。これにより、lazybuf がバッファを割り当てる必要があるかどうかを判断する際に、ボリューム名を除いたパス部分のみを考慮するようになります。
string() string:
- 変更前: return b.s[:b.w] または return string(b.buf[:b.w])
- 変更後: return b.volAndPath[:b.volLen+b.w] または return b.volAndPath[:b.volLen] + string(b.buf[:b.w]) この変更が最も重要です。lazybuf がバッファを割り当てなかった場合（つまり、パスが変更されなかった場合）、以前は b.s[:b.w] を返していました。これは、ボリューム名が失われる可能性がありました。新しい実装では、b.volAndPath[:b.volLen+b.w] を返すことで、元のボリューム名とクリーンアップされたパス部分を結合し、不要な文字列コピーを避けています。バッファが割り当てられた場合でも、b.volAndPath[:b.volLen] を使用してボリューム名を効率的に結合しています。

`Clean` 関数の変更

Clean 関数は、パスのボリューム名を処理する方法が変更されました。

VolumeName(path) から volumeNameLen(path) へ:
- 変更前: vol := VolumeName(path); path = path[len(vol):]
- 変更後: volLen := volumeNameLen(path); path = path[volLen:] VolumeName 関数が文字列を返す代わりに、volumeNameLen 関数がボリューム名の長さ（int）を返すようになりました。これにより、ボリューム名自体を文字列として生成するオーバーヘッドがなくなります。
lazybuf の初期化:
- 変更前: out := lazybuf{s: path}
- 変更後: out := lazybuf{path: path, volAndPath: originalPath, volLen: volLen} lazybuf の初期化時に、元のパス全体 (originalPath) とボリューム名の長さ (volLen) が渡されるようになりました。これにより、lazybuf が最終的なパスを構築する際に、ボリューム名を適切に扱うことができます。
最終的なパスの結合:
- 変更前: return FromSlash(vol + out.string())
- 変更後: return FromSlash(out.string()) lazybuf.string() メソッドが既にボリューム名を考慮して最終的なパスを返すようになったため、Clean 関数内で明示的にボリューム名を結合する必要がなくなりました。

`VolumeName` 関数の変更と `volumeNameLen` の導入

src/pkg/path/filepath/path.go に新しい VolumeName 関数が追加されました。この新しい VolumeName は、内部的に volumeNameLen を呼び出してボリューム名の長さを取得し、その長さに基づいて元のパスからボリューム名を抽出して返します。これは、以前のプラットフォーム固有の VolumeName 関数とは異なる役割を持ちます。
src/pkg/path/filepath/path_plan9.go, src/pkg/path/filepath/path_unix.go, src/pkg/path/filepath/path_windows.go の各ファイルで、既存の VolumeName 関数が volumeNameLen にリネームされ、その戻り値の型が string から int に変更されました。これにより、各プラットフォーム固有のボリューム名処理ロジックが、ボリューム名の「長さ」を返すことに特化するようになりました。
- Windows (path_windows.go): volumeNameLen は、ドライブレター（例: C:）やUNCパス（例: \\host\share）の長さを正確に計算して返します。
- Unix (path_unix.go) および Plan 9 (path_plan9.go): これらのシステムにはボリューム名の概念がないため、volumeNameLen は常に 0 を返します。

これらの変更により、Clean 関数は、パスのクリーンアップ処理中に、特にWindows環境で、既にクリーンアップされたパスが入力として与えられた場合に、不要な文字列の生成やメモリ割り当てを回避できるようになりました。これは、パフォーマンスの向上と、それに伴うビルドの安定化に貢献します。

コアとなるコードの変更箇所

`src/pkg/path/filepath/path.go`

lazybuf 構造体に volAndPath string と volLen int フィールドが追加。
lazybuf.index() メソッドで b.s が b.path に変更。
lazybuf.append() メソッドで b.s が b.path に変更。
lazybuf.string() メソッドのロジックが大幅に変更され、volAndPath と volLen を利用してボリューム名を考慮した文字列を返すように。
Clean 関数内で VolumeName の呼び出しが volumeNameLen に変更され、lazybuf の初期化時に volAndPath と volLen が渡されるように。
Clean 関数の最終的な戻り値の構築で vol + out.string() が out.string() に変更。
新しい VolumeName 関数が追加され、内部で volumeNameLen を呼び出すように。

`src/pkg/path/filepath/path_plan9.go`

VolumeName 関数が volumeNameLen にリネームされ、戻り値が string から int に変更され、常に 0 を返すように。

`src/pkg/path/filepath/path_unix.go`

VolumeName 関数が volumeNameLen にリネームされ、戻り値が string から int に変更され、常に 0 を返すように。

`src/pkg/path/filepath/path_windows.go`

VolumeName 関数が volumeNameLen にリネームされ、戻り値が string から int に変更され、Windowsパスのボリューム名の長さを計算して返すように。
IsAbs 関数内で VolumeName の呼び出しが volumeNameLen に変更。

コアとなるコードの解説

このコミットの核心は、path/filepath パッケージがパスをクリーンアップする際に、特にWindows環境でのボリューム名の扱いをより効率的にした点にあります。

lazybuf の強化: lazybuf は、パスの変更がなければ元の文字列のスライスを返し、変更があれば新しいバッファにコピーして返すという「遅延割り当て」のコンセプトに基づいています。このコミットでは、lazybuf が元のパス全体 (volAndPath) とボリューム名の長さ (volLen) を保持するようになりました。これにより、lazybuf.string() メソッドが、パスが変更されなかった場合でも、ボリューム名を含む正しい最終パスを、不要な文字列結合なしで返すことができるようになりました。これは、既にクリーンアップされたパスが Clean に渡された場合に、特に効果を発揮します。
volumeNameLen の導入と役割分担: 以前は、プラットフォーム固有の VolumeName 関数がボリューム名自体を文字列として返していました。しかし、Clean 関数が本当に必要とするのは、ボリューム名の「長さ」だけであり、その文字列自体を常に生成する必要はありませんでした。新しい volumeNameLen 関数は、各プラットフォーム固有のロジックでボリューム名の長さを int として返すことに特化しました。これにより、不要な文字列の生成とメモリ割り当てが回避されます。そして、path.go に新しく追加された VolumeName 関数は、この volumeNameLen を利用して、必要に応じてボリューム名文字列を抽出して返すという役割分担がなされました。これにより、必要なときにだけボリューム名文字列が生成されるようになり、全体的な効率が向上しました。

これらの変更により、Clean 関数は、入力パスが既にクリーンアップされている場合、特にWindows環境において、メモリ割り当てを最小限に抑え、パフォーマンスを向上させることが可能になりました。これは、Go言語の標準ライブラリが、細部にわたるパフォーマンス最適化を追求している良い例と言えます。

参考にした情報源リンク

Go CL 6344049: path/filepath: avoid allocation in Clean of cleaned path even on windows (fix build): https://golang.org/cl/6344049
- このコミットのレビューページであり、変更の意図や議論が詳細に記述されています。特に、lazybuf の設計思想や、Windowsパス処理の複雑性に関する議論が参考になります。
Go言語のソースコード: src/pkg/path/filepath/ ディレクトリ内の関連ファイル。
- path.go
- path_plan9.go
- path_unix.go
- path_windows.go これらのファイルは、コミットの変更内容を直接理解するために参照しました。
Go言語のドキュメント: path/filepath パッケージの Clean 関数に関する説明。
一般的なプログラミングにおけるメモリ割り当てと最適化に関する知識。
Windowsのファイルパス形式（ドライブレター、UNCパス）に関する一般的な知識。
Go言語のクロスプラットフォーム開発に関する一般的な知識。# [インデックス 13423] ファイルの概要