broofaの答えは、実際にはかなり洗練されています。印象的に賢く、本当に... rfc4122に準拠しており、多少読みやすく、コンパクトです。驚くばかり！
しかし、その正規表現、それらの多くのreplace()コールバック、関数呼び出しtoString()、およびMath.random()関数呼び出し（彼は結果の4ビットのみを使用し、残りを無駄にしている）を見ていると、パフォーマンスについて疑問に思われるかもしれません。確かに、joelptはで一般的なGUIDの速度を求めるためにRFCを廃止することさえ決定しましたgenerateQuickGUID。
しかし、速度と RFCへの準拠を取得できますか？はい、そうです！ 読みやすさを維持できますか？ええと...そんなことはないけど、ついていけば簡単です。
しかし、最初に、私の結果は、ブロッファと比較してguid（受け入れられた回答）、rfcに準拠していませんgenerateQuickGuid。
Desktop Android
broofa: 1617ms 12869ms
e1: 636ms 5778ms
e2: 606ms 4754ms
e3: 364ms 3003ms
e4: 329ms 2015ms
e5: 147ms 1156ms
e6: 146ms 1035ms
e7: 105ms 726ms
guid: 962ms 10762ms
generateQuickGuid: 292ms 2961ms
- Note: 500k iterations, results will vary by browser/cpu.
最適化の6回目の反復までに、私は最も人気のある回答を12 倍以上、受け入れられた回答を9 倍以上上回りました、とすることにより、高速非対応の答え2〜3倍。そして、私はまだrfc4122に準拠しています。
どのように興味がありますか？完全なソースをhttp://jsfiddle.net/jcward/7hyaC/3/と http://jsperf.com/uuid-generator-opt/4に配置しました
説明のために、broofaのコードから始めましょう：
function broofa() {
return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
return v.toString(16);
});
}
console.log(broofa())
したがってx、ランダムな16進数yとランダムなデータ（10RFC仕様に従って上位2ビットを強制することを除く）に置き換えられ、正規表現は- or 4文字としないため、それらを処理する必要はありません。とても、とても滑らかです。
最初に知っておくべきことは、正規表現と同様に関数呼び出しが高価であることです（彼は1つしか使用しませんが、マッチごとに1つずつ、32個のコールバックを持ち、32個のコールバックのそれぞれでMath.random（）とvを呼び出します。 toString（16））。
パフォーマンスに向けた最初のステップは、RegExとそのコールバック関数を削除し、代わりに単純なループを使用することです。これは、-と4文字を処理する必要があるのに対し、ブルームは処理しなかったことを意味します。また、文字列配列のインデックス作成を使用して、洗練された文字列テンプレートアーキテクチャを維持できることに注意してください。
function e1() {
var u='',i=0;
while(i++<36) {
var c='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'[i-1],r=Math.random()*16|0,v=c=='x'?r:(r&0x3|0x8);
u+=(c=='-'||c=='4')?c:v.toString(16)
}
return u;
}
console.log(e1())
基本的に、-またはを確認することを除いて同じ内部ロジック、4および（replace()コールバックの代わりに）whileループを使用すると、ほぼ3倍の改善が得られます！
次のステップは、デスクトップでの小さなステップですが、モバイルではまともな違いを生み出します。Math.random（）呼び出しを減らして、ランダムなビットの87％を捨てるのではなく、ランダムなバッファーを使用して、反復ごとにシフトアウトする代わりに、それらのすべてのランダムなビットを利用しましょう。それが役立つ場合に備えて、そのテンプレート定義をループの外に移動しましょう：
function e2() {
var u='',m='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx',i=0,rb=Math.random()*0xffffffff|0;
while(i++<36) {
var c=m[i-1],r=rb&0xf,v=c=='x'?r:(r&0x3|0x8);
u+=(c=='-'||c=='4')?c:v.toString(16);rb=i%8==0?Math.random()*0xffffffff|0:rb>>4
}
return u
}
console.log(e2())
これにより、プラットフォームに応じて10〜30％節約できます。悪くない。しかし、次の大きなステップでは、toString関数呼び出しを完全に排除し、従来の最適化であるルックアップテーブルを使用します。単純な16要素のルックアップテーブルは、toString（16）の処理をはるかに短時間で実行します。
function e3() {
var h='0123456789abcdef';
var k='xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx';
/* same as e4() below */
}
function e4() {
var h=['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'];
var k=['x','x','x','x','x','x','x','x','-','x','x','x','x','-','4','x','x','x','-','y','x','x','x','-','x','x','x','x','x','x','x','x','x','x','x','x'];
var u='',i=0,rb=Math.random()*0xffffffff|0;
while(i++<36) {
var c=k[i-1],r=rb&0xf,v=c=='x'?r:(r&0x3|0x8);
u+=(c=='-'||c=='4')?c:h[v];rb=i%8==0?Math.random()*0xffffffff|0:rb>>4
}
return u
}
console.log(e4())
次の最適化は別の古典です。ループの反復ごとに4ビットの出力のみを処理しているので、ループの数を半分にして、反復ごとに8ビットを処理します。RFC準拠のビット位置を処理する必要があるため、これはトリッキーですが、それほど難しくありません。次に、0x00〜0xffを格納するために、より大きなルックアップテーブル（16x16、または256）を作成する必要があり、e5（）関数の外で1回だけ作成します。
var lut = []; for (var i=0; i<256; i++) { lut[i] = (i<16?'0':'')+(i).toString(16); }
function e5() {
var k=['x','x','x','x','-','x','x','-','4','x','-','y','x','-','x','x','x','x','x','x'];
var u='',i=0,rb=Math.random()*0xffffffff|0;
while(i++<20) {
var c=k[i-1],r=rb&0xff,v=c=='x'?r:(c=='y'?(r&0x3f|0x80):(r&0xf|0x40));
u+=(c=='-')?c:lut[v];rb=i%4==0?Math.random()*0xffffffff|0:rb>>8
}
return u
}
console.log(e5())
引き続き256要素のLUTを使用して、一度に16ビットを処理するe6（）を試しましたが、最適化の効果が減少していることがわかりました。反復は少なかったものの、処理の増加により内部ロジックは複雑になり、デスクトップでも同じように実行され、モバイルでは約10％高速でした。
適用する最後の最適化手法-ループを展開します。ループ回数は決まっているので、技術的にはすべて手作業で書き出すことができます。私は、再割り当てし続けた単一のランダム変数rでこれを1回試しましたが、パフォーマンスは低下しました。しかし、4つの変数にランダムデータを事前に割り当て、次にルックアップテーブルを使用して、適切なRFCビットを適用することで、このバージョンはすべての変数をスモークします。
var lut = []; for (var i=0; i<256; i++) { lut[i] = (i<16?'0':'')+(i).toString(16); }
function e7()
{
var d0 = Math.random()*0xffffffff|0;
var d1 = Math.random()*0xffffffff|0;
var d2 = Math.random()*0xffffffff|0;
var d3 = Math.random()*0xffffffff|0;
return lut[d0&0xff]+lut[d0>>8&0xff]+lut[d0>>16&0xff]+lut[d0>>24&0xff]+'-'+
lut[d1&0xff]+lut[d1>>8&0xff]+'-'+lut[d1>>16&0x0f|0x40]+lut[d1>>24&0xff]+'-'+
lut[d2&0x3f|0x80]+lut[d2>>8&0xff]+'-'+lut[d2>>16&0xff]+lut[d2>>24&0xff]+
lut[d3&0xff]+lut[d3>>8&0xff]+lut[d3>>16&0xff]+lut[d3>>24&0xff];
}
console.log(e7())
Modualized： http://jcward.com/UUID.js -UUID.generate()
面白いことに、16バイトのランダムデータを生成するのは簡単です。トリック全体は、それをRFC準拠の文字列形式で表現することであり、16バイトのランダムデータ、展開されたループ、およびルックアップテーブルで最も厳密に達成されます。
私の論理が正しいことを願っています-この種の面倒なビットワークで間違いを犯すのは非常に簡単です。しかし、出力は私にはよく見えます。コードの最適化によってこの狂った乗り心地を楽しんだことを願っています！
注意してください：私の主な目標は、潜在的な最適化戦略を示し、教えることでした。他の回答では、衝突や真の乱数など、適切なUUIDを生成するために重要な重要なトピックについて説明します。